# Discovery for BI projects
Discovery for BI projects may be guided using the following supporting materials for planning interviews with a Client, specifying requirements for BI reports, and planning project milestones
[https://drive.google.com/drive/folders/1lvtTd0vWOlyzN2ZMZmWimH4NfUfSIr3W?usp=sharing](https://drive.google.com/drive/folders/1lvtTd0vWOlyzN2ZMZmWimH4NfUfSIr3W?usp=sharing)
A project kick-off presentation may be found here
[https://docs.google.com/presentation/d/1b6OZcJi0sV1nZDLhM674LGoaD\_6QCVNDTC6WL-R21Ik/edit?usp=sharing](https://docs.google.com/presentation/d/1b6OZcJi0sV1nZDLhM674LGoaD_6QCVNDTC6WL-R21Ik/edit?usp=sharing)
# Discovery Phase (BA)
Discovery is the first stage of implementation, where requirements are revealed, business need is analyzed to present an offer of technical realization, fix project scope, and set estimates. More information on the Discovery phase process can be found [**_here_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4441).
The main BA task is to minimize uncertainty.
The Discovery phase usually takes place after the [**_Presale_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7122).
## Discovery team
* BA, Tech Lead - must-have.
* Designer - if there is a focus on UX.
* PM, Subject Matter Experts (Data Scientist, DevOps, etc.) if there is a specific request.
* Sales representative, AM - to support and facilitate communication if needed.
## Preparation to Discovery
Prepare an agenda based on the Research Results and Planned Deliverables. Research may include but be not limited to learning the client's business model, competitors, market, company structure, business domain, and the main problems of this business domain. Knowledge of the issues common for particular business domains would be helpful, as they would intersect with the client's problems, enabling the Discovery team to hold more effective and professional discussions.
International companies such as Gartner, Forrester, Deloitte often publish market research for different business domains, so they can be used as a reliable source of information.
## Planned deliverables
* Business requirements - problem or opportunity - model business processes ([**_BPMN_**](https://businessanalystmentor.com/business-process-modelling-the-basics/)**_,_** [**_Flow-chart_**](https://www.lucidchart.com/pages/what-is-a-flowchart-tutorial)) or document them. Include success criteria, as they are crucial to measuring solution success in the future.
* Users and Roles - critical use cases, stakeholder requirements - what pains it solves, this should be related to key business processes success criteria.
* Context - [**_Context diagram_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-8688) - interfaces (entities) to understand how many interfaces should be developed - this intersects with use cases - types of data - data dictionary, data flow diagram. Define whether there are any integrations in place.
* **What** **features** \- in business meaning - are the main differentiators of the solution, and how does it differ from analog solutions?
* Quality attributes (source for non-functional requirements). Define points critical for our solution. Don't ask the client directly what performance it should be? - define options for them, so they select.
During the Discovery phase, it is essential to define standard rules for future communication and requirements for life circle management (RLCM). This information would be a background for the [**_Communication Plan_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7082) and [**_Requirements management plan_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7062).
In particular, it would be helpful to define how frequently we would communicate with a client and what communication channels to use.
Define the format for the requirements (user story, use case) and how they will be managed (check [**_Requirements management plan_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7062) for more details)
It is important to define the list of stakeholders needed from the client's side and agree with the client that they would be available for the discussion, so we can cover all needed questions.
## Prepare templates before the Discovery Phase
Key deliverables Templates
* [**_Vision and Scope_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7102) - the main deliverable from discovery.
* [**_Stakeholders register_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7482)_._
* [**_Communication plan_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7082)_._
* [**_Requirements management plan_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7062)_._
* [**_User stories_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7062), [**_use cases_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7682)_._
* List of quality attributes crucial for the industry (BABOK section 10.30.3)
## Discovery flow from BA perspective
| **STEPS** | **ARTEFACTS/ DELIVERY** |
| ---| --- |
| Kick-Off | Refined Agenda |
| Business Case Definition | Business Requirements |
| Functional Requirements Definition | Functional Requirement |
| Quality Attributes Definition | Non-Functional requirements |
| BA Process Definition | Communication plan, Requirements management plan |
| Summary | Vision and Scope document |
Quality Attributes may be defined during a workshop with relevant stakeholders - an Architect or Tech Lead are required persons for this activity.
## Final deliverables of the Discovery Phase
* **Refined Proposal**
* Refined Estimates
* Time
* Budget
* [**_Vision and Scope_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7102)
* Business requirements and success criteria
* User roles
* Feature List or Feature tree
* Solution context ([Context diagram](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-8688))
* Wireframes
* Prototype
* Refined Architecture Vision
* Technologies stack
* Architecture diagram
* Development team
# PMO Structure
[Ukrainian version of this guideline](https://docs.google.com/document/d/1SRCQgSOVfIh7iy-_qd72hEnXxHhR2P6guQJsxYEznm8/edit?usp=share_link)
The **Project Management Office (PMO)** at Devcom represents a management division that standardizes project-related governance processes, facilitates sharing of resources, tools, and existing techniques, methodologies, and develops custom approaches with subsequent tailoring.
Devcom's **PMO Mission**:
Create an environment of sustainable high performance of projects and their continuous improvement.
# Structure
The current hierarchy supports a flat structure type with the principal on top:
### **Director of PMO**
# ↓
#### Project Managers––Project Coordinators––Project Administrators––Business Analysts
More information about roles and responsibilities can be found in the [**Responsibility Matrix**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4101).
# PMO Core Principles
#### Provide project management guidelines that support consistency in how projects are delivered
This principle is supported by the variety of [**policies**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5301) related to project management processes, [**templates**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5281), and training during the [**onboarding**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4461) and throughout the career path. Our standardized tools, approaches, and knowledge nourish a common high-fidelity vision across projects and facilitate decisions that transcend individual project concerns.
#### **Offer project support with shared services to successfully combine the development approach and life cycle**
PMO exists as a supportive unit that wants to ensure fine delivery while maintaining direct control over some project phases and particular activities (planning, risk management, [**performance tracking**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4361), and delivery).
#### Be the second pair of eyes to oversee the company's projects
Oversight includes activities to follow the project status from the first day. The monitoring may occur in the presale phase, where business case requirements are needed to initiate a project, resource allocation to execute and deliver the project, and change requests approval to align project objectives.
#### **Serve as the center of growth, knowledge, compliance, and competence**
The PMO goals in perspective focus on:
* **sharing lessons** **learned** from retrospectives across the unit(s) to transfer valuable knowledge regularly;
* playing a **proactive role** in nurturing and retaining talented team members while developing management and leadership skills within project teams and across the company;
* **coaching** development teams, building agile skills and capabilities throughout the Devcom to support customer-centered objectives, and applying adaptive delivery for business initiatives;
* **mentoring** Clients (e.g., product owners) to be more effective in their roles and actively participate in creating value while executing their main responsibilities;
* implementing Devcom's strategy with investments in projects that deliver specific outcomes as part of its IT expertise.
We strongly believe that these activities strengthen project delivery. Please also see the [PMO vision for 2022](https://docs.google.com/presentation/d/15UtIKrdiFFKTvPPcjwhz9zGg5gIlE9fXh55tVlpt9fI/edit?usp=sharing).
# PMO As Shared Service
PMO serves Devcom in multiple ways based on the core PMO principles.
Activities are as follows but are not limited to:
* process assistance;
* general or specific consulting;
* service requests;
* presale activities;
* educational activities.
# Ground Rules and Code of Conduct
1. PMO members treat each other with respect at all times.
2. Each member accepts the [**responsibilities**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4101) and is accountable for their actions.
3. PMO strives to work collaboratively and uses a consensus approach when making team decisions.
4. Constructive feedback is a valuable part of our success, so we will not take offense, and all PMO members will ensure all feedback is provided in a constructive manner.
5. PMO recognizes and celebrates all individual and team accomplishments.
6. Project score sheets will be processed monthly by the **15**th day of the month.
7. All personal stuff is left aside before beginning any meetings or discussions to keep a better focus.
8. He who is late more than 3 minutes or absent from the PMO biweekly meeting without prior notification has to prepare a presentation for internal knowledge sharing or Devcom Talk.
9. We will give consideration to whoever is speaking and avoid sidebars or speaking over one another.
# PM Life Cycle & Career Path
[Ukrainian version of this guideline](https://docs.google.com/document/d/1c_ZBJdQbKP-Ct1gR_3BleiP75YnXQdrEYRDPDZv3T5k/edit?usp=share_link)
General [workplace rules](https://docs.google.com/document/d/1rRDlAhemfYHv3-1tKcR43lhaX1mr6AQB46sRzkpK3SM/edit) can be found on the Intranet. Other details can be found within the [starter pack](https://docs.google.com/document/d/1hyWsUX45AASfFU5LgAJaWV6zH8kPywkVG-z5f0xFuqw/edit). Other information is stored on the [Intranet](https://sites.google.com/devcom.com/dcintranet/home?authuser=0) as well.
Each project must have documentation stored either on the Client's side or Devcom's.
# PM Life Cycle Process
PMO has a further responsibility to adopt him when a Project Manager/Coordinator/Administrator completes the hiring cycle ([interview questions](https://docs.google.com/spreadsheets/d/1u5RiT74PzSTndCpBrZ7nacB4XS9oRHXtGGof7pUaD6g/edit#gid=407096084)) with the HR department. There are several stages involved:
### **Recruitment** → **Professional Development** → **Retention** → **Separation** → **Offboarding** → **Alumni**
1. **Recruitment** is part of the hiring process in collaboration with HR.
1. Attraction. There are two main reasons to scout:
1. One of the Units has just got a new project and opened a vacant spot for a project manager as a [request](https://docs.google.com/spreadsheets/d/1-moBUEaatg6ce95c_U6W_AqD8BgKZbgg7Au0N_TwFnQ/edit#gid=1776200419) for services.
2. On the other side, there might be no current need to fill in the gap in management for one of the projects; however, the company or Unit may submit the request. It is well-planned activity to shorten the employee lead time for upcoming opportunities from the sales and marketing side.
2. Interviewing. Based on the need (current or upcoming opportunity), a new project manager receives the information about the PMO role, its responsibilities, and a list of minimum requirements for this position, and fills in the [assessment](https://docs.google.com/forms/d/e/1FAIpQLSf0-OxLThJfSY1TZNYBYTaMzNBaewvxK7pbP6ShYXuC6i5HGA/viewform).
3. Onboarding**.** PMO facilitates the training and familiarization with current [policies](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5301) and best practices. The [**Guidelines**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4461?block=block-f0fce002-24f4-4a64-962c-acb86e8bbae8) section below enhances this process.
1. There is a review (employee feedback performance) meeting where an initial PDP plan has to be created after the onboarding period of 2 weeks.
2. At the end of the probation period, AM or the responsible person has to evaluate the PM skills again according to the [form](https://docs.google.com/forms/d/e/1FAIpQLSf0-OxLThJfSY1TZNYBYTaMzNBaewvxK7pbP6ShYXuC6i5HGA/viewform).
2. **Professional Development**. Any project work strengthens PM qualities, hard skills, and leadership, allowing them to utilize the knowledge of principles, techniques, and frameworks.
1. Ramp up. The acquaintance with the project goes along with Personal Development Plan (PDP). AM/PM/TL helps the newcomer familiarize themself with the existing project state.
2. Engagement. Besides regular project work, Devcom's PMO offers other activities that contribute to departmental growth, maturity, and the project manager's self-development.
3. Feedback. Effective feedback should be regular and less formal, especially during the spontaneous talk (meeting), to verify the task's progress.
3. **Retention**. PDP fosters a habit of continuous growth and being a T-shaped professional.
1. Recognition. The ability to empower project managers to improve how they do their work identifies PMO not only as supportive but provides the opportunity to lead people beyond the project (coaching, being part of the presale team, performing activities for other departments/units to help them reach their objectives).
4. **Separation**. Leaving a project goes hand in hand with the transition of duties, cross-training for anyone who may need to take over a project, and passing responsibilities along with documentation (including credentials, reassignment of tasks, transferring permissions, etc.). Work on a project has finished, and there is no further need for project management.
5. **Offboarding**. Termination of work could be due to various reasons:
1. 1. A project requires a less/more mature project manager.
2. The project manager changes his career path due to newly accepted responsibilities.
6. **Alumni**. The best-case scenario is when a project manager performs at the highest level and is promoted to another position. At this stage, people usually become mentors and can train others.
# Career Path
## Career Ladder
Becoming a project manager takes a lot of effort. The career path can start either:
1. with **_spontaneous_** taking the responsibility of being a project manager without prior education or
2. as a **_planned_** activity that begins with the commitment of becoming a project manager.
Regardless of the way, any employee can follow the career ladder in project management:
### Project Administrator / Project Coordinator
## ↓
### Project Manager (PM)
## ↙ ↘
### Delivery Manager (DM) Senior PM / Program Manager
## ↘ ↙
### Portfolio Manager / Account Manager
## ↓
### COO / VP of PM
## Responsibilities
The project manager must follow and lead Devcom's project management policies and procedures. A great project manager possesses strong leadership and managerial qualities to work with the team effectively. At the entry-level, the **Project Administrator / Project Coordinator** mostly plays the assistant on a project and executes duties delegated by the project manager.
The **Project Manager** is more autonomous and has the skills required to run projects and make strategic decisions. A more comprehensive set of [responsibilities](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4101) speaks about a certain level of professional maturity.
**Delivery Managers** must possess some technical background, be SMEs in any field, and focus on contributing value to the end state of the product by completing milestones.
**The Program Manager** can manage a few related projects concurrently, or **Senior PM** can operate within a big one with over 10-15 people. It requires another skill to work simultaneously with multiple teams, even if distributed globally. He also analyzes the business benefits (e.g., ideas, trends, market growth, optimization processes to reduce costs) of a project/program and oversees dependencies between projects. Solid knowledge of any scaled agile framework is required.
**The Portfolio Manager (AM)** must have several years (2+) of project management experience in Devcom under his belt. People are often entrusted with more significant, sometimes different, and more complex projects from different Clients, which require various stakeholder management techniques on top of general PM skills. However, the Portfolio Manager only oversees the projects, leads other project managers, and makes business-driven decisions.
**COO / VP of PM** usually oversees an organization's project management office portfolios of projects and supports other PMs. He also takes a leadership role in setting and maintaining standards for projects throughout the company. On the other hand, he must have a broad understanding of the company's objectives to align the best practices of management with the company's targets.
## Evaluation
The process of evaluation takes a few simple steps.
* AM or another responsible person asks each candidate to fill in the form.
* The starting point of one's evaluation begins with [self-assessment](https://forms.gle/xHGwM2ocpeJMuNk5A) (same name as the sheet) and grading each section.
* Account Managers conduct the second part and put their subjective grades, which are then compared. The revision and definition of a quantitative score is AM's responsibility and shall be part of the Personal Development Plan (PDP) and Performance Review Meeting (PRM).
# Guidelines
## General
1. [PMO Documents](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3821) section stores up-to-date information on handy templates and practices.
2. The [role of Project Manager](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4281) and [set of responsibilities](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4101) are defined in relation to Account Manager and Tech Lead positions.
3. The project manager is a leader, and thus must enhance leadership skills constantly (check [SEAL team](https://drive.google.com/drive/folders/1-1Tv6q_il-tm8Fgx4Phj9ZN1vCV4Udq_?usp=sharing) experience).
## Essential practices to follow
1. [Plan well](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4001).
2. [Work with requirements](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3981) (in collaboration with BA) to maximize value.
3. Facilitate project and task estimates using one of the [Estimation techniques](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4121).
4. Set and manage [quality](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4201) baseline; strive to increase overall project quality.
5. [Manage project stakeholders](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3721) to meet customer expectations.
6. Implement and manage the [Change management](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4241) guidelines
7. Ensure the [Definition of Done](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5341) is followed to avoid discrepancies in the completed scope.
8. Gather and utilize [feedback](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3901).
9. Record the [lessons learned](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4021) and update the [ground rules](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3841) within the Team(s).
## Best practices and recommendations
1. Per AM's direction, PM works with people
1. 1 to 1 meetings
2. Check [Team health](https://docs.google.com/forms/d/1vFPFcjRJy0jzNOV8gW-PSmlu7GkwmgTnvstFkWHhV2o/edit?usp=sharing) (monthly)
3. Participate in PDP, [performance reviews](https://sites.google.com/devcom.com/dcintranet/ld/step-by-step-instructions#h.vx1o2qb69eyh)
4. Check/track reported time in [DCM](https://rep.devcom.com/manager/) (own and teammates')
2. [Share the knowledge](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3961).
3. Establish [project support process](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4161) to provide proper maintenance after successful 'go-live'.
## Monitoring process
1. [Project health](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4361) is measured by various sets of KPIs. It's being tracked periodically (per month).
1. If there are Sprints involved, one must consider their length. In the case of 1, 2, or 4-week Sprints, it is easier to match the monthly timeline. For example, two 2-week Sprints (28 working days) fit even if they end after the 20th (e.g., 24th of May).
2. Communication with top management, the finance department, the HR department, and technical leadership provides insights into project status.
1. Top Management (AM, CEO):
1. Notify about project status (based on project scoresheet);
2. Escalate high-severity issues (unless PM and Tech Leads can resolve them).
2. PMO:
1. Address blockers related to management processes;
2. Request services, the assistance of processes set up/improvement;
3. Communicate about teammates who are available for involvement in another project;
4. Share the knowledge.
3. Finance:
1. The report of paid hours and missing hours in a monthly report.
4. HR:
1. Communicate about teammates who may leave the project;
2. Open the requests to hire new developers, QA, DevOps, etc.
5. CTO:
1. Inform about technical challenges or findings.
# PM Training Template
[Ukrainian version of this guideline](https://docs.google.com/document/d/1pmvH-NiW_gctZftVyokucs_Y4uIovdy18aw-5_Xdflc/edit?usp=share_link)
General [workplace rules](https://docs.google.com/document/d/1rRDlAhemfYHv3-1tKcR43lhaX1mr6AQB46sRzkpK3SM/edit) can be found on the Intranet. Other details can be found within the [starter pack](https://docs.google.com/document/d/1hyWsUX45AASfFU5LgAJaWV6zH8kPywkVG-z5f0xFuqw/edit).
# Training Program
Depending on the seniority level, the project manager shall pass the training and educate himself when starting the new role or advancing to a higher level of responsibility.
| **COMPETENCIES** | **Project Administrator** | **Project Coordinator** | **Project Manager** |
| ---| ---| ---| --- |
| **CLIENT MANAGEMENT** | | | |
| Stakeholder Management Guidelines
| **Not required** | **Optional** | **Mandatory** |
|
PMBOK 7th Ed
| **Not required** | **Optional** | **Mandatory** |
|
MSA
NDA
SOW
| **Not required** | **Optional** | **Optional** |
| **PROCESSES** | | | |
|
PMBOK 7th Ed
| **Not required** | **Mandatory** | **Mandatory** |
|
PMBOK 7th Ed
| **Not required** | **Optional** | **Mandatory** |
|
PMBOK 7th Ed
| **Not required** | **Not required** | **Mandatory** |
|
meetings
| **Optional** | **Mandatory** | **Mandatory** |
|
risk register
| **Not required** | **Not required** | **Mandatory** |
|
Project support
| **Not required** | **Optional** | **Mandatory** |
|
Jira
plugins
| **Optional** | **Mandatory** | **Mandatory** |
|
internal requests
| **Mandatory** | **Mandatory** | **Mandatory** |
|
Project health
| **Not required** | **Mandatory** | **Mandatory** |
| **SCOPE & SCHEDULE** | | | |
|
PMBOK 7th Ed
| **Not required** | **Mandatory** | **Mandatory** |
|
PMBOK 7th Ed
| **Not required** | **Optional** | **Mandatory** |
|
project requirements
| **Not required** | **Optional** | **Mandatory** |
| Estimate
| **Not required** | **Optional** | **Mandatory** |
|
changes
| **Not required** | **Optional** | **Mandatory** |
| Forecast planning
| **Not required** | **Optional** | **Mandatory** |
| **BUDGET** | | | |
|
| **Mandatory** | **Mandatory** | **Optional** |
|
| **Mandatory** | **Mandatory** | **Optional** |
|
vacations and days off
| **Not required** | **Optional** | **Mandatory** |
| **TEAM MANAGEMENT** | | | |
|
PMBOK 7th Ed
| **Not required** | **Optional** | **Mandatory** |
|
ground rules
| **Not required** | **Optional** | **Mandatory** |
|
Team health
| **Not required** | **Optional** | **Optional** |
| Share the knowledge
| **Optional** | **Mandatory** | **Mandatory** |
|
DevcomTalks
| **Optional** | **Optional** | **Mandatory** |
|
| **Not required** | **Not required** | **Mandatory** |
|
| **Not required** | **Optional** | **Mandatory** |
| **QUALITY** | | | |
|
PMBOK 7th Ed
| **Not required** | **Mandatory** | **Mandatory** |
|
PMBOK 7th Ed
| **Not required** | **Optional** | **Mandatory** |
|
Definition of Done
| **Not required** | **Optional** | **Mandatory** |
|
QA practices
| **Not required** | **Optional** | **Mandatory** |
| **COMMUNICATION** | | | |
|
feedback
| **Optional** | **Optional** | **Mandatory** |
|
| **Not required** | **Not required** | **Mandatory** |
| **SCRUM** | | | |
| Scrum Guide
| **Not required** | **Mandatory** | **Mandatory** |
| Twice the work in half the time
| **Not required** | **Optional** | **Optional** |
| User Stories Applied
| **Not required** | **Optional** | **Optional** |
| Scrum Guide Cheat Sheet
| **Not required** | **Optional** | **Optional** |
| Plan thoroughly
| **Not required** | **Mandatory** | **Mandatory** |
| Review
| **Not required** | **Mandatory** | **Mandatory** |
| Reflect and learn on past events
| **Not required** | **Mandatory** | **Mandatory** |
| **PROJECT MANAGEMENT TOOLS & TECHNIQUES** | | | |
| PMI Agile Practices
| **Not required** | **Optional** | **Optional** |
| Kanban Guide
| **Not required** | **Optional** | **Mandatory** |
| Mix of Scrum and Kanban
| **Not required** | **Not required** | **Optional** |
|
Nexus
internal Knowledge
Sharing
| **Not required** | **Not required** | **Optional** |
|
leadership
nurture followers
| **Not required** | **Optional** | **Mandatory** |
|
Part 1 - Responsibilities (Session 1 and 2)
template of Delegating Responsibility
| **Optional** | **Mandatory** | **Mandatory** |
|
recommended tools
| **Not required** | **Optional** | **Mandatory** |
# Mentorship
Mentoring is a reciprocal and collaborative relationship between a senior and junior Devcom employee for the mentee’s growth, learning, and career development.
There is an emphasis on organizational goals, culture, career goals, advice on professional development, and work-life balance. Effective mentors often act as role models and sounding boards for their mentees and guide to help them reach their goals:
* Increase employee retention;
* Discipline management skills;
* Drive feedback process;
* Help to set OKRs/goals for PDP.
Since there are many models and techniques, Devcom suggests **Peer E-mentoring** that reflects adjustments to the business approach nowadays. Participants are usually in the same role, position, department, or similar experiences. These peers may pair up to offer support for each other, and it can be group or 1-to-1 mentoring. E-mentoring emphasizes the role of the internet in connecting people using audio and video calls.
To find a mentor, one has to ask the supervisor or use PDP meetings to define people who can assist in reaching the planned goals. Since mentorship implies a temporary responsibility, it relates primarily to gaining achievements during the PDP execution.
Feel free to pick up a mentor among:
* Professional(s) you respect;
* Trusted colleagues;
* Leaders are offered by the HR department, direct supervisors;
* Or just ask anyone in your team who can help to grow.
Choose the [meeting format](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7382) for better cross-communication. The frequency is agreed upon between a mentor and mentees.
## Who can be a mentor
Being a mentor means combining the skills of a professional Coach, Career Consultant, Trainer, Sage, and even Wizard.
The role of a Mentor is pretty straightforward - to nurture people by creating value for them, just like in project management, using various techniques and even involving other people.
Mentors are servant leaders and perform within the defined timelines until the value is achieved. This means that mentors can be gradually switched and rotated. To become a mentor, one simply needs to possess skills that are useful for others and the ability to coach people.
Moreover, a mentor should help with PDP execution:
* Regular checkpoints;
* Experience-based advice;
* Progress tracking;
* Mutual accountability;
* Results verification;
* Develop a strategy for timely task execution.
# Sample of Items to Learn
| **ITEMS** | **Assignee** | **Due date** |
| ---| ---| --- |
|
Part 1 - Responsibilities (Session 1 and 2)
template of Delegating Responsibility
| |
|
|
Scrum Guide
Kanban Guide
| | |
|
ground rules
| | |
|
Team health
| | |
|
Scrum guide cheat sheet
Agile & Scrum
| | |
|
PMBOK 6th in Pictures
| |
|
|
Project health
| | |
|
recommended tools
| | |
|
Mike Cohn
| | |
|
User Stories Applied
Estimation techniques
| | |
|
PMP Exam Prep
| | |
|
PMBOK 7th Edition
| | |
All additional information can be found on the [PM onboarding](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4461) page.
# Project Manager's Manual
[Ukrainian version of this guideline](https://docs.google.com/document/d/10ho2bqIccfOkDRtZ_mOOdeWs-t4XeidXVlqAXIa1uZQ/edit?usp=share_link)
A project manager must possess certain knowledge depending on the responsibilities he accepts.
Other information is stored on the [Intranet](https://sites.google.com/devcom.com/dcintranet/home?authuser=0).
The basic difference among the roles below is described in the [PM Life Cycle & Career Path document](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4461?block=block-ed88dcef-4138-4051-b8c9-64302007d946) and [responsibilities](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4101) list. The project manager must follow and lead Devcom's project management policies and procedures.
# Project Administrator Manual
As the main responsibility of a Project Administrator (PA) is to work with reports and numbers, he must use DCM and learn its capabilities.
## **Processes**
### Must know
* Arrange purposeful [meetings](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3921), like [project kick-off](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7502).
* Create [internal requests](http://tt.dev.com.ua/) for Devcom Admins (_the requests may be sent on behalf of other employees_).
## **Budget**
### Must know
* Prepare, revise, and send Clients invoices (_DCM, QuickBooks_).
* Analyze reported hours and invoiced hours (_DCM, task tracking tool_).
* Report the trends or fluctuations to Project Managers and Account Managers.
## **Communication**
### Nice to know
* Provide and receive timely [feedback](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3901) about his work.
# Project Coordinator Manual
A Project Coordinator (PC) assists the project manager and executes delegated duties.
## **Client management**
### Nice to know
* Handle communication through [Stakeholder Management](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3721).
* Understand the [MSA](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4401), [NDA](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4061), [SOW](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4041).
## **Processes**
### Must know
* Follow the chosen development approach.
* Measure [Project health](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4361) periodically (_Goal 80%+_).
* Arrange purposeful [meetings](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3921) with all attributes.
* Create [internal requests](http://tt.dev.com.ua/) for Devcom Admins (_the requests may be sent on behalf of other employees_).
### Nice know
* Understand [Project support](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4161) flow (_including SLA_) after initial release.
* Practical knowledge of Atlassian tools ([_Jira_](https://sites.google.com/devcom.com/dcintranet/ld/step-by-step-instructions#h.raoi0l75yb8l) _and_ [_plugins_](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4461?block=block-5328bf1d-c8ff-49ae-b662-40842a6eb022)_, Confluence_).
## **Scope & Schedule**
### Must know
* Work with the [project requirements](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3981).
* Coordinate the [Estimation](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4121) process.
### Nice to know
* Maintain [Requirements Management Plan](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7062) applicability.
* Proactively monitor the [change](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4241)log.
* Assist with [forecast planning](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3881) activity.
## **Budget**
### Must know
* Prepare, revise, and send Clients invoices (_DCM, QuickBooks_).
* Analyze reported hours and invoiced hours (_DCM, task tracking tool_).
* Report the trends or fluctuations to Project Managers and Account Managers.
* Prepares reports for PM about the team's [vacations and days off](https://docs.google.com/document/d/1rRDlAhemfYHv3-1tKcR43lhaX1mr6AQB46sRzkpK3SM/edit).
## **Team management**
### Must know
* [Share the knowledge](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3961).
* Attend and participate in [DevcomTalks](https://sites.google.com/devcom.com/dcintranet/devcom-talks?authuser=0).
* Hold regular 1-to-1 meetings with team members.
### Nice to know
* Maintain the [ground rules](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3841) (_Agile charter_) up-to-date and ensure the team follows them.
* Monitor the [Team's health](https://docs.google.com/forms/d/1vFPFcjRJy0jzNOV8gW-PSmlu7GkwmgTnvstFkWHhV2o/edit?usp=sharing) (_every month_).
## Quality
### Must know
* Maintain the [Definition of Done](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3941) up-to-date and ensures the team follows.
### Nice to know
* Promote existing and assist in developing new [QA practices](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4201).
## **Communication**
### Must know
* Provide and receive timely [feedback](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3901) about his work.
## Scrum
### Must know
* Understand the [Scrum Guide](https://scrumguides.org/scrum-guide.html).
* Follow the [Planning](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4001) [process thoroughly](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4001).
* It is essential to have daily meetings (sync) for coordination.
* Hold the [Review](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4381) [meeting](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4381) of the completed work during the Sprint.
* Facilitate [Retrospective](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5421) [events to learn](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5421).
## **Project management tools & techniques**
### Must know
* Use the principles [of Delegating Responsibility](https://docs.google.com/document/d/1QhyBvrZuN67xaMPmNL-uAyiZgu6eDydjXXTgTgQHDb4/edit?usp=sharing) and coordinate actions inside the team.
* Maintain the [minimum project documentation](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3821) up-to-date using one of the [recommended tools](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4461?block=block-aefa7b7b-3e87-455a-b1fd-66694dcb3900).
### Nice to know
* Know the [Kanban Guide](https://www.scrum.org/resources/blog/kanban-primer-scrum-teams) (the _theoretical part, at least_).
* Promote [leadership](https://www.youtube.com/watch?v=MNSAolUgFYQ&t=1078s) and [nurture followers](https://www.youtube.com/watch?v=PRh80RyT74I).
# Project Manager Manual
A Project Manager has the skills to run projects from scratch, freedom of choice when defining tools, approaches, and processes, and makes strategic decisions.
## **Client management**
### Must know
* Handle communication through [Stakeholder Management](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3721) [Guidelines](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3721).
### Nice to know
* Understand the [MSA](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4401), [NDA](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4061), [SOW](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4041).
## **Processes**
### Must know
* Choose the development life-cycle approach.
* Arrange purposeful [meetings](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3921) with all attributes.
* Use the [risk register](https://docs.google.com/spreadsheets/d/1YeR-EaRwxDKKJ_RDYbnSKh5wsJ7DbrriAv9C8AMfIF0/edit?usp=sharing) to visualize the project uncertainty with further management.
* Establish [Project support](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4161) flow (_including SLA_) after initial release.
* Practical knowledge of Atlassian tools ([_Jira_](https://sites.google.com/devcom.com/dcintranet/ld/step-by-step-instructions#h.raoi0l75yb8l) _and_ [_plugins_](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4461?block=block-5328bf1d-c8ff-49ae-b662-40842a6eb022)_, Confluence_).
* Create [internal requests](http://tt.dev.com.ua/) for Devcom Admins (_the requests may be sent on behalf of other employees_).
* Measure [Project health](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4361) periodically (_Goal 80%+_).
## **Scope & Schedule**
### Must know
* Work with the [project requirements](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3981) or delegate to PC or BA.
* Create the [Requirements Management Plan](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7062) and maintain its applicability.
* Establish the rules and technique of the [Estimation](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4121) process.
* Control the [change](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4241) [management](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4241) work.
* Coordinate [forecast planning](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3881) activity.
## **Budget**
### Must know
* Monitor the reported time (_DCM, task tracking tool_).
* Reconcile team members' [vacations and days off](https://docs.google.com/document/d/1rRDlAhemfYHv3-1tKcR43lhaX1mr6AQB46sRzkpK3SM/edit) with project plans.
### Nice to know
* Manage client info and invoices (_DCM, QuickBooks_).
## **Team management**
### Must know
* Create the [ground rules](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3841) (Agile charter) and ensure the team follows them.
* Monitor the [Team's health](https://docs.google.com/forms/d/1vFPFcjRJy0jzNOV8gW-PSmlu7GkwmgTnvstFkWHhV2o/edit?usp=sharing) every month.
* [Share the knowledge](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3961) and promote it inside the team.
* Attend and participate in [DevcomTalks](https://sites.google.com/devcom.com/dcintranet/devcom-talks?authuser=0).
* Mentor others.
* Hold regular 1-to-1 meetings with team members.
## Quality
### Must know
* Maximize the value and control timely delivery.
* Create and maintain the [Definition of Done](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3941) up-to-date and ensure the team follows.
* Monitor existing [QA practices](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4201) and assist in developing new ones.
## **Communication**
### Must know
* Provide and receive timely [feedback](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3901) about his work.
## Scrum
### Must know
* Understand and interpret the [Scrum Guide](https://scrumguides.org/scrum-guide.html), and act as a Scrum Master.
* Create and follow the [Planning](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4001) [process thoroughly](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4001).
* Coordinate daily meetings (sync).
* Hold the [Review](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4381) [meeting](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4381) of the completed work.
* Facilitate [Retrospective](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5421) [events to learn](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5421).
## **Project management tools & techniques**
### Must know
* Promote [leadership](https://www.youtube.com/watch?v=MNSAolUgFYQ&t=1078s) and [nurture followers](https://www.youtube.com/watch?v=PRh80RyT74I).
* Use the principles [of Delegating Responsibility](https://docs.google.com/document/d/1QhyBvrZuN67xaMPmNL-uAyiZgu6eDydjXXTgTgQHDb4/edit?usp=sharing) and coordinate actions inside the team.
* Define the [minimum project documentation](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3821), and keep it up-to-date using one of the [recommended tools](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4461?block=block-aefa7b7b-3e87-455a-b1fd-66694dcb3900).
### Nice to know
* Aware of [PMI Agile Practices](https://drive.google.com/file/d/15tcMZNWVypLXDEDL41OAZDPVDDEOBVi1/view?usp=sharing).
* Know the [Kanban Guide](https://www.scrum.org/resources/blog/kanban-primer-scrum-teams) (_theoretical part, at least_).
* Use the [Mix of Scrum and Kanban](https://www.scrum.org/resources/blog/understanding-kanban-guide-scrum-teams) as one of the agile approaches.
* Master the [Nexus](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5081) or similar techniques for scaled Scrum ([internal Knowledge](https://sites.google.com/devcom.com/dcintranet/devcom-talks/non-tech-talks?authuser=0#h.lxut3zlco4ho) [Sharing](https://sites.google.com/devcom.com/dcintranet/devcom-talks/non-tech-talks?authuser=0#h.lxut3zlco4ho)).
# PMO Service Ordering
[Ukrainian version of this guideline](https://docs.google.com/document/d/1FxOyErDaOvGby0dIgIxMsIT6KfTOQACIxRubM7a3oAA/edit?usp=share_link)
# PMO Services
PMO serves Devcom in multiple ways based on the core PMO principles.
Activities are as follows but are not limited to:
* process assistance
* general or specific consulting
* project evaluation
* resources requests
* presale activities
* educational activities.
## The Flow
### Request a service using the template
### ↓
### Open status for the request
### ↓
### Approved **←****_(_****_Yes_****_)_****←** In Review →_(__Need more info__)_→On Hold
## ↓
### **_(_****_No_****_)_**
## ↓
### Rejected
## The Process of Ordering
One can request PMO services using the [**template**](https://docs.google.com/spreadsheets/d/1-moBUEaatg6ce95c_U6W_AqD8BgKZbgg7Au0N_TwFnQ/edit#gid=1776200419)**:**
1. The **Requester** has to fill out the details:
1. Resource type
2. Involvement (%)
3. Purpose
4. Start and End date (if known)
5. and notify the Approver using email and/or skype.
2. After the service was ordered, it had the status **Open**.
3. The **Approver** or other responsible person must reply no later than the next business day to notify about resource availability and further provision in the **Comment** section and set status **In Review**.
4. A service has a positive decision if **Approved**; otherwise, it can also be **Rejected** or put **On Hold****.**
Due to limited resources, it is **strongly recommended** to make requests proactively. The sooner it is sent, the better quality of service one will receive. Please consider the average time to hire in-house employees, which is **10** business days.
PMO shifts from being a project watchdog to orchestrating cooperation among top managers, business units, clients, and development teams.
## Hiring (resource request)
There will likely be no free project manager waiting on a bench. For the full-time involvement of an employee, PMO has to check with Account Managers (AM) if anyone is available to start soon.
In case a negative answer is received, PMO collects the requirements for this position and places the request to the HR department according to their policy. The requester is still responsible for providing the position requirements and monitoring the hiring process.
After the employee is hired, PMO notifies the AM to begin [onboarding](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4461?block=block-78aaa8f3-39ee-46f3-84dd-0af5d83bded2).
TEXT in **_bold_** **_italic orange (_****_including links in_** **_light blue_****_)_** is meant to be adopted for every position.
### Hiring requirements for Students (Project Managers/Coordinators) can be listed as in the template below
**Project information (****_AM should provide_****):**
* Project
* Team
* Client
* Currently used methodology
* Job ad
**Job responsibilities:**
* Assist with project processes and documentation
* Report to the supervisor about arising issues and risks
* Сontinually seek opportunities for improvements
**Required experience and skills:**
* Completed PM training (preferably with certificate/diploma)
* **_Theoretical_** knowledge of SDLC and agile methodologies
* **_Good_** interpersonal analytical skills
* **_Good_** planning skills
* **_Good_** English (intermediate or above)
**Would be a plus:**
* General understanding of the areas of application programming, internet, database, and system design
* Familiarity with Atlassian products (Jira, Confluence)
* Technical background (QA, developer)
* Experience in working on IT projects
**Professional growth:**
* Internal and external events for professional development
* Personal development plan
* Mentorship program
* Challenging tasks
* The company supports your initiatives
### Hiring requirements for Project Coordinators can be listed as in the template below
**Project information (****_AM should provide_****):**
* Project
* Team
* Client
* Currently used methodology
* Job ad
**Job responsibilities:**
* Help teams to achieve project objectives
* Assist with project scope, schedule, and quality
* Report to Project Manager about arising issues and risks
* Provide analytics to the Project manager based on project metrics
* Prepare reports for Clients, provide updates, escalate necessary issues to the Project Manager
* Monitor teams' consistent time tracking
* Assist with multiple projects
* Сontinually seek opportunities to increase customer satisfaction
* Maintain project documentation
**Required experience and skills:**
* **_1+_** year of experience as IT Project Coordinator
* **_Good_** knowledge of SDLC and agile methodologies
* **_Good_** interpersonal analytical skills
* **_Good_** people management skills
* **_Good_** tactical planning skills
* Excellent verbal and written communication skills
* General understanding of the areas of application programming, internet, database, and system design
* Familiarity with Atlassian products (Jira, Confluence)
* Experience in working on **_small (up to 10 people)/medium (up to 15 people)/ large (over 20 people)_** projects
* **_Good_** English (intermediate or above)
**Would be a plus:**
* Ability to act as a Scrum master on the project(**_s_**)
* Technical background (QA, developer)
* Pre-sales activities
* Set up of new processes in pair with the existing project manager
**Professional growth:**
* Internal and external events for professional development
* Personal development plan
* Mentorship program
* Be part of PMO
* Challenging tasks
* The company supports your initiatives
### Hiring requirements for **Project** Managers can be listed as in the template below
**Project information (****_AM should provide_****):**
* Project
* Team
* Client
* Currently used methodology
* Job ad
**Job responsibilities:**
* Plan, organize, lead, and motivate teams to achieve project objectives
* Manage project scope, schedule, and quality
* Manage issues and risks
* Ensure implementation of the software development practices to meet customer expectations
* Ensure required quality of service in regards to the agreed terms
* Make decisions based on project metrics
* Act as a Scrum master on the project(**_s_**)
* Communicate with stakeholders, including Client representatives (prepare reports, provide updates, escalate necessary issues)
* Takeover part of operational activities in regards to business analysis
* Assist with pre-sale-related activities
* Lead multiple small projects
* Create & maintain project documentation
**Required experience and skills:**
* **_3+_** years of experience as IT Project Manager
* **_Strong_** experience to start projects from scratch
* **_Strong_** knowledge of agile methodologies (Scrum, Kanban)
* **_Strong_** people management skills
* **_Strong_** strategic and tactical planning skills
* **_Strong_** understanding of PMBOK practices
* Excellent verbal and written communication skills
* Good interpersonal analytical skills
* **_Good_** understanding of the areas of application programming, internet, database, and system design
* Hands-on experience with Atlassian products (Jira, Confluence)
* Experience in managing **_small (up to 10 people)/medium (up to 15 people)/ large (over 20 people)_** projects
* **_Strong_** English (upper-intermediate or advanced)
**Would be a plus:**
* Certifications (PMP, PSM, or similar)
* Technical background (QA, developer)
* Pre-sales activities
**Professional growth:**
* Internal and external events for professional development
* Personal development plan
* Mentorship program
* Be part of PMO
* The company supports your initiatives
### Hiring requirements for Senior **Project** Managers / Program Managers can be listed as in the template below
**Project information (****_AM should provide_****):**
* Project
* Team
* Client
* Currently used methodology
* Job ad
**Job responsibilities:**
* Plan, organize, lead, and motivate teams to achieve project objectives
* Manage project scope, schedule, and quality
* Manage issues and risks
* Ensure timely delivery to meet customer expectations
* Ensure required quality of service in regards to the agreed terms
* Make decisions based on project metrics and reports
* Be ready to lead Scrum ceremonies on the project(**_s_**)
* Communicate with stakeholders, including Client representatives (prepare status reports, provide updates, escalate necessary issues)
* Lead multiple projects
* Create & maintain project documentation
* Become SME in one of the product certifications
**Required experience and skills:**
* **_5+_** years of experience as IT Project Manager
* **_Strong_** experience starting projects from scratch
* **_Strong_** knowledge of scaled agile methodologies (Nexus, SoS, LeSS, or similar)
* **_Strong_** experience managing a few projects at a time
* **_Strong_** people management and leadership skills
* **_Strong_** strategic planning skills
* **_Strong_** understanding of PMBOK practices
* Excellent verbal and written communication skills
* **_Strong_** interpersonal analytical skills
* **_Strong_** understanding of the areas of application programming, internet, database, and system design
* Hands-on experience with Atlassian products (Jira, Confluence)
* Experience in managing **_medium (up to 15 people)/ large (over 20 people)_** projects
* **_Strong_** English (advanced)
**Would be a plus:**
* Certifications (PMP, PSM, or similar)
* Experience related to certification of the products (**_depending on the domain_**)
* Technical background (QA, developer)
* Pre-sales activities
**Professional growth:**
* Internal and external events for professional development
* Personal development plan
* Mentorship program
* Be part of PMO
* The company supports your initiatives
Additional requirements are based on the project peculiarities and can be added deriving from the [responsibilities](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4101).
### Assignment to a Project
Process of Project Manager/Coordinator being assigned to a project: PMO must provide or hire (in cooperation with the HR department)
Based on resource availability, PMO formally assigns a project manager/coordinator to a project.
The process takes the following steps:
1. Approval of resource availability. The project manager with the required qualification is available or hired (signed offer).
2. [Onboarding step](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4461?block=block-b64df242-7134-473c-865c-77dc04105e69). The designated project manager gets familiar with PMO and general project management guidelines in Devcom.
3. Project assignment. AM continues to onboard the project manager to a project. It involves but is not limited to:
1. The acquaintance with the team (if available);
2. Hold a meeting by introducing a project manager to the team. Let others briefly talk about themselves, describing their names, roles, and hobbies;
4. The acquaintance with other stakeholders (if available);
1. Daily meetings are best for introduction to the Client. Keep it brief and send a follow-up email to other stakeholders with a description of the new PM's primary duties and responsibilities;
2. Project current processes (if available). Describe the good and weak working processes, and familiarize with documented rules;
3. Project documentation (if available).
5. The supervisor (usually AM or project administrator) records in DCM available details, such as the employee's start date.
# PMO Knowledge Base
General [workplace rules](https://docs.google.com/document/d/1rRDlAhemfYHv3-1tKcR43lhaX1mr6AQB46sRzkpK3SM/edit) can be found on the Intranet. Other details can be found within the [starter pack](https://docs.google.com/document/d/1hyWsUX45AASfFU5LgAJaWV6zH8kPywkVG-z5f0xFuqw/edit). Other information is stored on the [Intranet](https://sites.google.com/devcom.com/dcintranet/home?authuser=0).
Each project must have documentation stored either on Client's side or Devcom's.
# Guidelines
## General
1. [PMO Documents](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3821) section stores up-to-date information on handy templates and practices.
2. The project manager is a leader, and thus must enhance leadership skills constantly (check [SEAL team](https://drive.google.com/drive/folders/1-1Tv6q_il-tm8Fgx4Phj9ZN1vCV4Udq_?usp=sharing) experience).
# Tools
1. It is recommended to use a task-tracking system during project execution:
1. [Jira](https://sites.google.com/devcom.com/dcintranet/ld/step-by-step-instructions#h.raoi0l75yb8l)
1. Suggested plugins:
1. [Agile Velocity Chart Gadget Cloud](https://marketplace.atlassian.com/apps/1223065/velocity-chart-for-confluence-cloud?hosting=cloud&tab=overview)
2. [Time Reports Cloud](https://marketplace.atlassian.com/apps/1212077/time-reports?hosting=cloud&tab=overview)
3. [Panorama view](https://marketplace.atlassian.com/apps/1219417/panorama-hierarchy-structure-for-jira?hosting=cloud&tab=overview)
4. [Open API (Swagger) Integration](https://marketplace.atlassian.com/apps/1219386/open-api-swagger-integration?hosting=cloud&tab=overview)
5. [Issue Checklist for Jira](https://marketplace.atlassian.com/apps/1220209/issue-checklist-for-jira-free?hosting=cloud&tab=overview)
6. [Clone Projects and issues](https://marketplace.atlassian.com/apps/1218652/deep-clone-for-jira?hosting=cloud&tab=overview&source=googlead1&utm_vendorID=1213041&utm_source=google&utm_medium=cpc&utm_campaign=1584183592&utm_content=381003453351&utm_term=deep%20clone%20for%20jira&gclid=Cj0KCQiA15yNBhDTARIsAGnwe0WOnpDuRxqjAv_R4dTOyF64pOInWRFe7sU1UlyG_KOIP8g4YHqR57kaAlYCEALw_wcB) with Deep clone
7. Integrations with Google services, messengers
8. [Advanced Roadmaps](https://www.atlassian.com/software/jira/guides/advanced-roadmaps/overview#what-are-advanced-roadmaps) (available with Premium account)
2. Project Migration:
1. Read [step-by-step manual](https://support.atlassian.com/migration/docs/perform-a-cloud-to-cloud-migration-for-jira/)
2. Check the [Admin permissions](https://support.atlassian.com/migration/docs/prepare-sites-for-a-cloud-to-cloud-migration/) depending on the actions one has to take
3. Check the [data type and details](https://support.atlassian.com/migration/docs/what-migrates-in-a-cloud-to-cloud-migration-for-jira/) that **can** and **cannot** be migrated
4. Install the plugins/apps and services on the destination site to avoid issues
5. [Users and groups](https://support.atlassian.com/migration/docs/how-cloud-to-cloud-migration-manages-users-and-groups/) are migrated separately
6. Good luck with migration!
2. Trello
3. Asana
4. Redmine
5. Other tools/services must be approved by PMO.
2. Project documentation should be stored within
1. Confluence
2. Google docs
3. MS Office
4. ClickUp
5. [Nuclino](https://www.nuclino.com/)
6. Other tools/services must be approved by PMO.
3. For other activities, PM should use
1. Roadmap
1. [Roadmunk](https://roadmunk.com/features/product-roadmap-tool)
2. [Product Board](https://www.productboard.com/product/roadmaps/)
3. [TeamGantt](https://www.teamgantt.com/features)
4. [Wrike](https://www.wrike.com/vw/)
5. [Smartsheet](https://www.smartsheet.com/)
2. [Proposify](https://app.proposify.com/login) when building & sending proposals, NDA, SOW, MSA
3. Slack, Skype, MS Teams for communication
4. [Velocity range calculator](https://www.mountaingoatsoftware.com/tools/velocity-range-calculator)
5. [Tool](https://easyretro.io/) [for a](https://easyretro.io/) [cool r](https://easyretro.io/)[etrospective](https://easyretro.io/)
6. Communications:
1. Slack
2. MS Teams
# Certifications
1. [Scrum Master](https://www.scrum.org/professional-scrum-certifications/professional-scrum-master-assessments)
1. [The Scrum Guide Comparison](https://amazing-outcomes.de/en/what-we-offer/agile-resources/comparison-scrum-guide-2020-and-scrum-guide-2017)
2. [Manifesto for Agile Software Development](https://agilemanifesto.org/)
3. [Principles behind the Agile Manifesto](https://agilemanifesto.org/principles.html)
4. [Scrum basics](https://www.youtube.com/watch?v=XSkzidmM9mk)
5. [Tips](https://drive.google.com/file/d/1jdZ16x4dug2K4ecmLXS8on7elvgXLs7i/view?usp=sharing) (by Zenovia S., PSM I)
2. [Project Management Professional (PMP)](https://www.pmi.org/certifications/project-management-pmp)[®](https://www.pmi.org/certifications/project-management-pmp)
1. To get prepared, one can try to pass [Udemy course](https://www.udemy.com/course/pmp-pmbok6-35-pdus/?utm_source=adwords&utm_medium=udemyads&utm_campaign=ProjectManagement_CA&utm_content=deal4584&utm_term=_._ag_73032116572_._ad_533229913679_._kw_project+management+certification_._de_c_._dm__._pl__._ti_kwd-138949064_._li_1030503_._pd__._&matchtype=e&gclid=Cj0KCQiAuP-OBhDqARIsAD4XHpcZD18_U3MnMNgUr1Dm8o8jrxG--ugeMwFJPhsHHyMqleigS77bOF4aAqagEALw_wcB)
2. [PM Study circle](https://pmstudycircle.com/)
3. Articles and advice: [first](https://dou.ua/forums/topic/35772/) & [second](https://dou.ua/lenta/articles/how-to-pmp-exam/)
3. [SAFe](https://scaledagile.com/safe-certification/)
1. [Training & learning](https://www.scaledagileframework.com/)
# Knowledge Base
1. [Scrum Guide](https://scrumguides.org/scrum-guide.html)
2. [Kanban Guide](https://www.scrum.org/resources/blog/kanban-primer-scrum-teams)
3. [Mix of Scrum and Kanban](https://www.scrum.org/resources/blog/understanding-kanban-guide-scrum-teams)
4. [Methodologies comparison matrix](https://docs.google.com/spreadsheets/d/1ydsJ2BeB8XXfOowgDOXStAldx3SQMGH2mIJp3z_LxRU/edit#gid=0)
5. Mike Cohn [channel](https://www.youtube.com/c/MikeCohn)
1. [Getting Agile with Scrum](https://www.youtube.com/watch?v=0tC_CxeIdQc)
2. [User Stories](https://www.youtube.com/watch?v=6q5-cVeNjCE)
3. [Agile Estimating](https://www.youtube.com/watch?v=37zfyncCpkA&t=776s)
4. [Agile Estimating and Planning: Planning Poker](https://www.youtube.com/watch?v=gE7srp2BzoM)
5. [Agile Estimating and Planning: Product Backlog Estimating Units](https://www.youtube.com/watch?v=lpdzY6zP6RA)
6. [Agile Estimating and Planning: Why Plans Go Wrong](https://www.youtube.com/watch?v=NUVzQ5JaqtI)
7. [Agile Estimating and Planning: More Reasons Plans Go Wrong](https://www.youtube.com/watch?v=kzael7pFcYg)
8. [Advanced Topics in Agile Planning](https://www.youtube.com/watch?v=D2r2KryYAaY&t=2644s)
9. [Leading a Self-Organizing Team](https://www.youtube.com/watch?v=x8P68CqHc_A&t=2346s)
10. [Scrum Repair Guide: Selecting the Right Scrum Sprint Length](https://www.youtube.com/watch?v=BgyuKgPdyw4)
11. [Scrum Repair Guide: Grooming the Product Backlog](https://www.youtube.com/watch?v=IJwKKW9Y1xE)
12. [Scrum Repair Guide: Leaving Time for Testing - How to Spread Work Evenly Across the Sprint](https://www.youtube.com/watch?v=KPmZkNBnOTU)
13. [Scaling Agile with Distributed Teams](https://www.youtube.com/watch?v=ZdQ4nE-h2C4&t=1s)
14. [Agile and the Seven Deadly Sins of Project Managing](https://www.youtube.com/watch?v=U41uxRtjdLI&t=35s)
15. [Being agile](https://www.youtube.com/watch?v=VlQ2ls_hm8o)
6. [Agile & Scrum](https://www.youtube.com/watch?v=2uFA3f74D0Q) philosophy
7. Books:
1. [PMI 6th Edition](https://drive.google.com/file/d/1v4KkTyeDqAEKSE0YAISIiH08Vc4ykHY5/view?usp=sharing)
2. [PMBOK 6th in Pictures](https://drive.google.com/file/d/1QkX_bQn3mB9zir7j7bPQUuIScMfT_o29/view?usp=sharing)
3. [PMBOK Process Map](https://drive.google.com/file/d/1Bj5-47aN9W1p5H3Ibf66BWlnqXjMUFtq/view?usp=sharing)
4. [PMBOK 7th Edition](https://drive.google.com/file/d/1Su5WHz29U53WXKhk0YP8x6cdWdbwklh8/view?usp=sharing)
5. [PMP Exam Prep](https://drive.google.com/file/d/1CUfKzVJ_qODKExwErJwFB8Q5WjFJh0Yj/view?usp=sharing) (2013)
6. [PMI Agile Practices](https://drive.google.com/file/d/15tcMZNWVypLXDEDL41OAZDPVDDEOBVi1/view?usp=sharing)
7. [User Stories Applied](https://drive.google.com/file/d/1DEG5YoN5Y2Z-viYgso4SC05jg3oi9CzM/view?usp=sharing)
8. [Scrum Guide Cheat Sheet](https://drive.google.com/file/d/1caCxoklIIAk1vDYejaDF38ARwmUipwC0/view?usp=sharing)
9. [Twice the work in half the time](https://drive.google.com/file/d/1ibgbCLZahS63wqalgEkbdnEocBsLs_qa/view?usp=sharing)
8. Nexus
1. [Nexus guide](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5081)
2. [Intro](https://scrumorg-website-prod.s3.amazonaws.com/drupal/2016-06/An%20Introduction%20to%20the%20Nexus%20Framework%20-%20June%202016_0.pdf)
3. [Overview](https://scrumorg-website-prod.s3.amazonaws.com/drupal/2018-10/NexusOverview-A4.pdf)
4. [Cross-team refinement](https://scrumorg-website-prod.s3.amazonaws.com/drupal/2016-08/Cross-Team%20Refinement%20in%20Nexus%20whitepaper_0.pdf)
5. [Sample of implementation](https://scrumorg-website-prod.s3.amazonaws.com/drupal/2016-10/They%20Thought%20It%20Was%20Overkill%20-%20The%20Nexus%20Daily%20Scrum%20Whitepaper.pdf)
6. [Nexus integration team](https://scrumorg-website-prod.s3.amazonaws.com/drupal/2016-11/The%20Nexus%20Integration%20Team.pdf)
# Knowledge Sharing Sessions
| **DATE** | **SPEAKER** | **SUBJECT** |
| ---| ---| --- |
| 01/13/2021 | @Andrii Bordun | [What to do with Responsibility?](https://docs.google.com/presentation/d/1bMT9zf3QFREpI1ULF-ieTRLDD0whjd-7XVBx2NRapUw/edit#slide=id.p1) ([recording](https://drive.google.com/file/d/1NcYn7c58RN2vUWPGRPxFZ2GvGyhc8mNS/view?usp=sharing)) |
| 02/04/2022 | @Andrii Bordun | [PMBOK 7th Ed](https://docs.google.com/presentation/d/1KOvLyXcwPomTP3fNZme4VpZWFY1tY1UlYwoeh9_fs_s/edit?usp=sharing) |
| 04/14/2022 | Patrick Lencioni | [The ideal team player](https://www.youtube.com/watch?v=PRh80RyT74I) |
| 04/28/2022 | @Zenoviia Slipchenko | PSM I tips ([recording](https://drive.google.com/file/d/1jdZ16x4dug2K4ecmLXS8on7elvgXLs7i/view?usp=sharing)) |
| 05/12/2022 | Fredrik Haren | [What is creativity?](https://www.youtube.com/watch?v=Eqcdb8kpujI&t=4s) |
| 06/09/2022 | Simon Sinek | [Start with WHY](https://www.youtube.com/watch?v=MNSAolUgFYQ&t=1078s) |
| 06/23/2022 | @Zenoviia Slipchenko | [Effective Retrospectives](https://docs.google.com/presentation/d/1HqsSVClTZaAuwVrWnEklR4vyfNNfOujbTuO23VQ9MdU/edit#slide=id.gbc4037c81a_0_68) ([recording](https://drive.google.com/file/d/1TfKWp9ZFRj0eHgUZ13HzcKDgpi1lfpfn/view?usp=sharing)) |
| 07/07/2022 | VALVE | [Valve Handbook review](https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployeeHandbook.pdf) |
| 07/21/2022 | @Zenoviia Slipchenko | [Refinement - tips](https://docs.google.com/presentation/d/1XY735NEyZnYx2qclBiQrI6Kg-KFDRF1X/edit?usp=sharing&ouid=112040268533485302076&rtpof=true&sd=true) ([recording](https://drive.google.com/file/d/1SIrLfQWhi24UOe9JKD7uyVQSoqaoPgaC/view?usp=sharing)) |
| 08/18/2022 | @Elina Lapka | [Communication Styles](https://docs.google.com/presentation/d/1AKyujQeR54kY8DRpr8PwaNPkOZ3Q60qZO9sQrk7X5NQ/edit?usp=sharing) ([recording](https://drive.google.com/file/d/191Z_2HExzOcuTiKqQ1PFtIo-Ka778M9-/view?usp=sharing)) |
| 09/01/2022 | @Elina Lapka | Information Mapping Approach ([recording](https://drive.google.com/file/d/118w4MaI_xcsVWQUnp3f4HvjEU0S-deU6/view?usp=sharing)) |
| 09/29/2022 | @Andrii Bordun | [Workshop](https://docs.google.com/spreadsheets/d/1sW6tsEbgiGDVpQ_vl4QHh8zce6Ij1zw4VThLApGWTek/edit#gid=1747319413): Expectations & Reality |
| 10/27/2022 | @Pavlo Stelmakh | [Motivation](https://docs.google.com/presentation/d/1RhkC3wgbzX83A-osO_DGXuPqdCL-JuiOPQEZG9V88Bg/edit#slide=id.g166af2e3688_0_319) ([recording](https://drive.google.com/file/d/1HGf0SyL1T50W2wdDTcCIL2On3AJEl_Oi/view?usp=sharing)) |
| 11/24/2022 | @Andrii Bordun | Workshop: Would you rather... |
| 12/08/2022 | @Zenoviia Slipchenko | [Effective stand-ups](https://docs.google.com/presentation/d/1y54dUxU_GfWjbhg2A3Ndk3z_mfou_GytBL0SZHovX9U/edit?usp=sharing) ([recording](https://drive.google.com/file/d/13rY2gQxheivkmnJLeZyAKD6BhJgbqif2/view?usp=share_link)) |
| 01/19/2023 | @Andrii Bordun | [Secrets of Power Negotiating](https://drive.google.com/file/d/1Ok4YmnHf93VWQZwE2lzZTLHA1LrikXOR/view?usp=share_link) (1-6 [Chapters](https://docs.google.com/presentation/d/1akGg_NUhaSUkYN8qwb8GUvayy8RKUqzgT4xHLycCPLk/edit?usp=sharing)) |
| 02/02/2023 | @Olena Ishchenko | [Sprint Planning Practical Skills](https://docs.google.com/presentation/d/1EJM6WaxzD5o21nUfBhkT1NhzN8qWDFLeK4tD-lOCbKU/edit#slide=id.p1) ([recording](https://drive.google.com/file/d/1umQzLFWiQlUhDXhcqxq7us-UmODv8t9w/view?usp=sharing)) |
| 02//2023 | @Andrii Bordun | [Secrets of Power Negotiating](https://drive.google.com/file/d/1Ok4YmnHf93VWQZwE2lzZTLHA1LrikXOR/view?usp=share_link) (7-13 [Chapters](https://docs.google.com/presentation/d/1akGg_NUhaSUkYN8qwb8GUvayy8RKUqzgT4xHLycCPLk/edit?usp=sharing)) |
| 03/3/2023 | @Andrii Bordun | [Secrets of Power Negotiating](https://drive.google.com/file/d/1Ok4YmnHf93VWQZwE2lzZTLHA1LrikXOR/view?usp=share_link) (14-18 [Chapters](https://docs.google.com/presentation/d/1akGg_NUhaSUkYN8qwb8GUvayy8RKUqzgT4xHLycCPLk/edit?usp=sharing)) |
| 04/13/2023 | @Liliia | [Advanced Roadmaps](https://drive.google.com/file/d/11m7SPNygbFp1oWlg0BroxLSpoHbcUfY0/view?usp=share_link) |
| 05/11/2023 | @Andrii Bordun | Project Support |
# [!!!] Project Management Template
Please check the [**General Guidelines**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4281) for more information
# Checklist
| **ITEMS** | **RESPONSIBLE ROLE** |
| ---| --- |
|
NDA
| CEO/AM |
|
MSA
| CEO/AM |
|
SOW
| CEO/AM |
|
| CEO |
|
| AM |
|
| AM/PA |
|
internal kick-off
meeting
| AM |
|
| AM/PM |
|
| BA/PM |
|
| BA/PM |
|
| PM |
|
Communication plan
Stakeholder management plan
Requirements management plan
| PM, BA |
|
| AM |
|
| AM |
|
| Tech Lead |
|
| AM/Tech Lead |
|
| PM |
|
| PM |
|
kick-off
| AM/PM |
# Project Scoresheet
[Ukrainian version of this guideline](https://docs.google.com/document/d/1SdHFzpNtHUKbOvkhYAv-Xw8uSGzKEvD8Lh7DSgnZXjY/edit?usp=share_link)
# Guideline
| **GROUP** | **DEFINITION** | **TOOLS** |
| ---| ---| --- |
| **VELOCITY** | Regardless of the task tracking system, you must be able to easily find the numbers for the **Planned** and **Actual** scope of work.
The **Actual** value represents your _Velocity_. The **Deviation** is the relation between the two values above.
Earned value is a relation between the two values above. | Any task tracking System (Google docs, Trello, Jira, Asana, RedMine, MS Office) |
| **USER STORIES / TASKS** | **The** **Quantity of planned user stories/tasks** is the number of total planned tasks in the sprint backlog (period).
**Refined tasks** tell the readiness of the upcoming scope. It is recommended to plan ahead and use the 'forecasting' approach.
**Blocked tasks** may appear during the Sprint due to poor planning, ambiguous requirements, 3rd party components, etc. It would be nice to identify such tasks asap.
**Not estimated tasks** can be included only if they have low priority and one expects minor clarifications or refinement. You have to be comfortable with the T-Shirt sizes then. | Any documents' space (Google docs, MS Office, Confluence) |
| **QA** | **Defects injection rate** is the simple ratio between bugs reported during the period and the total number of tasks that generate value (tasks like "general meeting", "project onboarding," etc., most likely are not generating value to the project).
**Defects injection rate before Production** shows the ratio between bugs reported on every Environment but Production and the total number of tasks that generate value.
**Defects found before Production** will indicate the number of issues QA representatives find during testing other than in Production environments. These are issues that are identified as errors caused by the scope developed earlier. The tasks that go back and forth from developer to QA are considered as part of the process of development and no 'Bug' issue shall be created. _Once the task has gone through code review, QA flow, and defects are found in later stages/environments, one must record that as a bug._
**Defects found in Production** are more red flags for defects that were carried out in the Production environment.
**Defects reported by the Client** represent the issues that were not identified by QA representatives in the Production environment and pointed out by the Client's representatives (any of the stakeholders on the Client side).
**Defects closed** is simply a number of all issues closed in the current period regardless of when they were identified.
**Defects fix time ratio** shows the relation between the time spent on fixing all types of bugs and development time during the period in every environment.
**Created vs Closed ratio** shows the difference between Defects closed and those that were found. | Any task tracking System (Google docs, Trello, Jira, Asana, RedMine, MS Office) |
| **HR** | **The** **Capacity index** helps to plan better team capacity and forecast the feasibility of estimated scope based on team member presence. One can use the historical records to forecast throughput, e.g., there were 80h of absence reported in August by 15 people in the team. 1-((80/8)/15/20) = 0.97 capacity (20 is the average number of month working days).
**Average experience per employee** gives an understanding of how long people stick with a project. The conclusions based on this metric can be quite different but definitely show the stability level. For long-term projects, it indicates that people grow, and the project itself is challenging and interesting enough to learn and bring value to the end-users.
Speaking of **Team turnover,** one must worry only if it is often greater than 0, as team members leave the project.
**People agility** is closely related to risk management. It shows the easiness of one's replacement and its impact on a project.
**CSAT** is a way of receiving the Client's feedback quicker and understanding his point of view of how the project looks from his perspective based on criteria.
**Team evaluation by the Client's supervisor** ranks the team from the Client's perspective within predefined categories and points to improvements. | Any task tracking System (Google docs, Trello, Jira, Asana, RedMine, MS Office) and document's space (Google docs, MS Office, Confluence) |
| **DEVELOPMENT** | **\[CODE STYLE\] {Severity} Error** and **Warnings** are watchdogs of code style according to the rules that must be agreed upon and added. One can calculate them in relation to builds and all rules, respectively.
**\[CODE STYLE\] Duplication** should be as low as possible to maintain the DRY principle.
**\[DATABASE\] Migrations count** can tell whether changes to the database are controlled by any means and are easy to revert.
**\[DATABASE\] Failed migrations ratio** helps to identify whether a team has enough knowledge to work correctly with the database. Also, mind the **\[DATABASE\] Unit tests**.
**\[SCM\] Commits in relation to estimates, Pull requests per task, Pull requests without the reviewer's comments** are important as they tell about tasks complexity and code quality part.
**\[SECURITY CODE ANALYSIS\] Bug, Warning, Error** are necessary to monitor the security piece and look for the weak spots.
**\[UNIT TESTS\] Count, Coverage** is essential to save time later on manual testing; however, unit tests are not cheap and easy to maintain, especially at the beginning of the project.
**Performance testing** is represented by multiple metrics and must be assessed based on requirements (how many users to support, page time load, etc.).
To reduce the complexity of understanding the code, the **Commenting** coverage should help.
The **Index** **of Project Architecture** is a framework for assessing the quality, maintainability, and supportability of a software engineering project. | SonarQube; InspectCode by JetBrains; DB: FlyWay by RedGate; Liquibase; Git; TFS; JMeter; BlazeMeter |
| **FINANCE** | **Gross Margin** roughly shows the profitability of the project.
One can see the project's growth through the **Revenue growth rate**.
**Invoiced hours vs Reported hours** shows the ratio between reported hours in DCM and those included in the invoice. **Aggregated overhead hours vs Period invoiced hours** defines the ratio between the aggregated non-billed hours and standard billable hours per period.
**Client Rating** clearly shows the Client's share in relation to others from the company's portfolio. N/A NOW.
THE AFOREMENTIONED FINANCIAL METRICS MAY BE MEASURED IN RELATION TO GOALS AND COUNTED IN POINTS. | DCM, QuickBooks, KUB |
# Template
[https://docs.google.com/spreadsheets/d/1BzgSMPm1CK6\_DbvQ1vrB5Vtbc8\_n03EVoOhaDAdtVsY/edit?usp=sharing](https://docs.google.com/spreadsheets/d/1BzgSMPm1CK6_DbvQ1vrB5Vtbc8_n03EVoOhaDAdtVsY/edit?usp=sharing)
# Unit 1
# Account Manager
Igor Bilokuryy
# Projects
* DA
* IME
* Keller Interiors
* Strada
* TrueTeam
* UnCut
[https://docs.google.com/spreadsheets/d/1t7xF8UGrnszQzRXyO7o4jeOHyjoVhyNvsh8HUlA4\_gU/edit#gid=0](https://docs.google.com/spreadsheets/d/1t7xF8UGrnszQzRXyO7o4jeOHyjoVhyNvsh8HUlA4_gU/edit#gid=0)
# Unit 2
# Account Manager
Igor Kruzhylko
# Projects
* PyramydAir
[https://docs.google.com/spreadsheets/d/1L5dlMtbb-b64OduSGc8c5QORk-ylc3iIj0cEftWKAI8/edit#gid=1741019799](https://docs.google.com/spreadsheets/d/1L5dlMtbb-b64OduSGc8c5QORk-ylc3iIj0cEftWKAI8/edit#gid=1741019799)
# Unit 3
# Account Manager
Sviatoslav Lavryk
# Projects
* CHE Services
* EMS
* Sharable
[https://docs.google.com/spreadsheets/d/1fThwF22jQhrxDSfhPboNLS-qUFdsWZDnTiB4GptNgY0/edit#gid=1901048721](https://docs.google.com/spreadsheets/d/1fThwF22jQhrxDSfhPboNLS-qUFdsWZDnTiB4GptNgY0/edit#gid=1901048721)
# Unit 4
# Account Manager
Taras Vons
# Projects
* ASME
* HS Auctions
* SureTrak
[https://docs.google.com/spreadsheets/d/1Papa\_f41aVRiM7fGsACxt3r6LzfGwOkC5MJn2vKdaUo/edit#gid=447690995](https://docs.google.com/spreadsheets/d/1Papa_f41aVRiM7fGsACxt3r6LzfGwOkC5MJn2vKdaUo/edit#gid=447690995)
# Unit 5
# Account Manager
Taras Zherukha
# Projects
* JNS
[https://docs.google.com/spreadsheets/d/1jB5bmi-R7dNylgmZk8CHCoT7Qb8dBSiv9\_OfHVb9fgc/edit#gid=243718580](https://docs.google.com/spreadsheets/d/1jB5bmi-R7dNylgmZk8CHCoT7Qb8dBSiv9_OfHVb9fgc/edit#gid=243718580)
# PMO Documents
[Ukrainian version of this guideline](https://docs.google.com/document/d/1tyNQD_BK8hUWQy7O3P-xv89mRQ7mGDwHETHTB9gzWRA/edit?usp=share_link)
Project documentation is created by a project manager to manage, control and deliver the project value. Each project must have documentation stored either on the Client's side or Devcom's.
In other words, it is recording the key project details and producing the documents required to implement it successfully.
The list of documents varies for each project. The essential three functions of documentation substantiate it:
* to make sure that project requirements are fulfilled;
* to establish traceability concerning what has been done, who has done it, and when;
* to create better visibility of processes.
# Benefits of Project Documentation
* **_Faster_** **_new employee onboarding_**. Good project documentation gives new team members access to all the knowledge that has been collected throughout the projects, both past and ongoing. New team members can immediately understand decisions made in the past and find relevant information without asking others on the team over many weeks.
* **_Better cross-team alignment_****.** Thorough documentation brings clarity and transparency to what everyone is working on. As a result, decisions and discussions don't get scattered over chat and email, less time is spent in meetings, and work is less likely to get duplicated.
* **_More effective_** **_knowledge sharing_**. The insights and lessons learned from one project can be transferred to new projects. Capturing and sharing this knowledge can help you develop new best practices, prevent repeated mistakes, and continuously improve your team's performance.
# Basic Documentation For a Project/Phase
## Project Initiation
During the first few meetings, all known information that a **Client** (and/or **Product Owner**) possesses must be collected and stored within standardized documents. This is the period when primary business need is defined initially.
* [**Project Charter**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4221) (Project charter is sometimes also known as the project overview statement. A project charter includes high-level planning components of a project, laying the foundation for the project)
* [**Statement Of Work**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4041) (SOW is made at the outset of a project and outlines everything that needs to go into your project, including the business case).
* [**Non-Disclosure Agreement**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4061) [](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4061)(NDA is a legally binding contract that establishes a confidential relationship. The parties signing the agreement agree that sensitive information they may obtain will not be made available to others).
* [**Master Service Agreement**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4401) (MSA is a contract made between two or more parties in which they both agree to most of the terms used to govern any future agreements or future transactions).
## Project Planning
The main job of the **Project Manager** at this point is to define all **stakeholders** who may impact the project in any way. He should also analyze the known scope, divide it into phases, and develop separate stages for project success. It would be nice to have a Business Analyst involved.
A **Tech Lead** validates the proposed solution within given resources and constraints. He defines the preliminary tech stack which will be used for development.
It is the right time to agree upon the quality and its measurement. Also, the [**Definition of Done**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5341) (DoD) is an essential part of any project phase.
To sum up, the steps above, creating a Project/Agile Charter to determine responsibilities and document high-level details is required.
Then comes the most challenging and interactive part, project planning, creating PMP (**project management plan**), and determining the required documents.
The resource planning process is an essential part when it comes to commitment.
A team creates a backlog of functional pieces to work with, usually broken down into tasks by following the plan. The main point is to see whether the scope can be completed simultaneously with other tasks.
If any is required, the next important piece falls under procurements or would be more beneficial than custom development.
* [**Business Requirements**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3981) **Document** (This is a complete description of the system to be developed. It contains all interactions users will have with the system and non-functional requirements).
* [**Stakeholder Management**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3721) **Document** (It establishes clear guidelines for communication among the project’s stakeholders, management of their expectations, involvement & impact).
* [**Sprint Planning**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4001) **Document** (The process is represented and documented as the list of items agreed by the team to be completed at the end of the iteration. It could be reflected in the [forecast planning](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3881)).
## Project Execution
It is worth stressing the importance of having an alternative plan if unpredictable circumstances occur regarding risk management. It is continuous and seamlessly integrated within the other processes.
If we work with Agile methodologies, estimating the backlog is easier and quicker, at least for the first iteration (Sprint). If it is not Agile, we are agile and adjust the processes.
In addition to that, it must be clear to a Client that the accumulation of technical debt must be avoided at any cost by using such practices as code refactoring. It must be part of the regular development process.
The complete schedule of deliverables depends on the backlog items estimation.
The project budget considers the needs, resources, risks, quality assurance, KPIs**,** and other costs.
* [**Change Management**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7702) **Document** (This document states exactly what must be changed, how it might alter any pre-existing plans and existing functionality for your project, and how to plan the mitigation of the disruption that the change could cause to the project creation process).
* [**Risk Management**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7022) **Document** (This document is used to consider the potential project risks involved and to record the best ways that you can respond to them as a team).
## Project Monitoring
Our goal is to make adjustments quickly, follow the plan, and work with the team effectively leading it.
There are quite a few metrics regarding this point, like team building activities and the level of customer satisfaction to be measured regularly.
It is a common practice to get feedback on the completed work, challenges, and achieved milestones to match the Client’s needs and/or requests.
Comparison of [KPIs with baselines](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4361) leads to reacting to changes and reviewing the risks to manage contingencies. Periodical confirmation that we are heading in the right direction is the green light to managerial activities and keeping the team motivated.
During the monitoring and controlling activities, the project manager oversees the processes and may create other documents on demand. We use documentation, such as a Stakeholder Communication Document, project roadmap, and project status report to ensure that the project work is implemented according to the plan. Feel free to use other documents to keep a project or individual work on track (e.g., [**OKR**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5161)).
## Project Closure
Once the project or phase has been finalized and before the celebrations start, you need to formally round things off by moving into the closure process.
Recording the lessons learned casually would be helpful as we may create company policies based on them.
Another informative document contains the credentials for different services we may use while working on the project. Keeping and/or handing over the code clean and safe is our responsibility.
After the final Client's feedback is given, we may consider that the phase is fully completed and all information is properly recorded for future reference.
The closing activities usually end up with greetings of successful completion and open ability of the subsequent improvements, updates, and maintaining the Client's success.
* [**Sprint Review**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4381) **Document** (It represents the visual part of deliverables done during the Sprint. Also, another essential part of the meeting is to receive the feedback, which has to be recorded and processed)
* [**Sprint Retrospective**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5421) **Document** (This document sets out what all have learned from the project as a team. It gives everyone an opportunity to put forward formal suggestions for what might go differently next time).
* [**Project Support**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4161) **Flow** (This artifact is a guide and sort of after-sale agreement with warranties explaining how to work and process stakeholders' requests. This can also be included in the SOW or other agreements).
* [**Project Closure**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7322) **Document** (This document is written confirmation that all the invested parties approved the completed project or phase. Effectively, they agree that the project has been kept on track and that the expectations of all of its stakeholders have been met).
# POLICIES
# Agile Suitability Guidelines
[Ukrainian version of this guideline](https://docs.google.com/document/d/1IIfio81yvHmo74WeUKM45GNJSZppGmHt4NENu_vKWLs/edit?usp=share_link)
# **Guideline**
## **Agile suitability: why and when using agile?**
Project work can be marked as **definable** and **high-uncertainty** work.
### Definable
* A straightforward procedure that has proved successful on similar projects in the past (e.g., the production of a car)
* The process is well understood
* Low level of uncertainty and risk.
### High-uncertainty work
* New design, problem-solving, incompleted before work is exploratory
* Requires subject matter experts to collaborate and solve problems to create solutions (e.g., doctors, teachers, lawyers).
Assess the project, both in the requirements and the means of delivery, to determine the best approach for the [**project's life cycle**](https://drive.google.com/file/d/1QQMTyKqfnLpVuV4q_41VUnOVHMHtEhDM/view).
Some teams have evolved project life cycles to use iterative and incremental approaches. Many teams discover that when they explore the requirements iteratively and deliver incrementally more often, the teams adapt to changes more easily. These iterative and incremental approaches reduce waste and rework because the teams gain feedback.
These approaches use:
* Very short feedback loops
* Frequent adaptation of process
* Reprioritization
* Regularly updated plans, and
* Frequent delivery.
# **Suitability Assessment Chart**
## Steps
Define the lifecycle of the project. How does it assess the suitability of the approach? Organizational and project attributes are assessed under three main categories:
* **Culture**. Is it a supportive environment with buy-in for the approach and trust in the team?
* **Team**. Is the team of a suitable size to be successful in adopting agile; do its members have the necessary experience and access to business representatives to succeed?
* **Project**. Are there high rates of change? Is incremental delivery possible? How critical is the project?
Questions in each category are answered, and the results are plotted on a radar chart. Clusters of values around the center of the chart indicate a good fit for **agile** approaches. Results around the outside indicate a **predictive** approach may be more suitable. Values in the middle portion (between agile and predictive) indicate that a **hybrid** approach could work well.
## **Life Cycle For Your Project**
Acceptance of the agile philosophy before starting work:
* Timeboxing
* User involvement
* Iterative development.
Iterative, incremental, and agile approaches work well for projects that involve new or novel tools, techniques, materials, or application domains. They also work well for projects that:
* Require research and development
* Have high rates of change
* Have unclear or unknown requirements, uncertainty, or risk; or
* Have a final goal that is hard to describe.
By building a small increment and then testing and reviewing it, the team can explore uncertainty at a low cost in a short time, reduce risk, and maximize business value delivery. This uncertainty may be centered on:
* Suitability and requirements (is the right product being built?)
* Technical feasibility and performance (can this product be made this way?)
* Or process and people (is this an effective way for the team to work?).
All three of these characteristics - product specification, production capability, and process suitability - typically have elements of high uncertainty.
No life cycle can be perfect for all projects. Instead, each project finds a spot on the continuum that provides an optimum balance of characteristics for its context. Specifically,
* **Predictive life cycles**. Take advantage of things that are known and proven. This reduced uncertainty and complexity allow teams to segment work into a sequence of predictable groupings.
* **Iterative life cycles**. Allow feedback on partially completed or unfinished work to improve and modify that work.
* **Incremental life cycles**. Provide finished deliverables that the customer may be able to use immediately.
* **Agile life cycles**. Leverage both the aspects of iterative and incremental characteristics. When teams use agile approaches, they iterate over the product to create finished deliverables. The team gains early feedback and provides customer visibility, confidence, and product control. Because the team can release earlier, the project may provide an earlier return on investment because the team delivers the highest value work first.
# Definition of Done (Guidelines)
[Ukrainian version of this guideline](https://docs.google.com/document/d/1F05WqlKTspMRpIuMD8u7wmZt-CxXXWM5yfOg_E2Qpz0/edit?usp=share_link)
Find the [**Template here**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3941)
# Guideline
The Definition of Done (DOD) provides a checklist that usefully guides pre-implementation activities: discussion, estimation, and design. It limits the cost of rework once a feature has been accepted as “done”. An explicit contract limits the risk of misunderstanding and conflict between the development team and the Client. More about DOD can be found [here](https://www.scrum.org/resources/blog/done-understanding-definition-done).
# Checklist
The items below form the checklist to verify whether backlog items are "**Done.**"
1. Unit tests passed
2. Acceptance criteria for each issue are met
3. Documentation is added
4. Security protocols are not broken
5. Functional tests passed
6. Non-functional requirements are met
7. Code is reviewed
8. The product owner accepts the User Story.
Definition of Done can be applicable to multiple environments. Thus, one can consider **DOD** for multiple environments.
# Example of Project Environments
# Distributed Teams & Contractors
[Ukrainian version of this guideline](https://docs.google.com/document/d/1BbiUtnYh8eRkukSR0HqGFl7f-omxgKAIHenc4PmhYD0/edit?usp=share_link)
# Guideline
The most significant advantage of slow scaling is that it allows the organization to limit risk and validate assumptions of whether it can meet its goals with its current knowledge and capabilities. Another advantage is that growing teams slowly reduce complexity by limiting the number of people involved and reducing cross-team dependencies when allocated in different places and/or countries.
Large distributed meetings are complicated, and planning is especially so. Effective planning requires the participation of everyone.
Distributed collaboration technology helps (e.g., online meetings (zoom, skype, slack, etc.), virtual whiteboards (Mirro, Lucidcharts, Mindmeister), and cloud-based planning tools (Jira or similar tools)), but they don’t solve the fundamental problem of engaging everyone.
Before having a distributed team involved, regardless if it is a 3rd party service provider/integrator or a remote in-house team, a project manager must consider the following:
* Learn the possible time difference to avoid miscommunication during the schedule planning;
* Consider the cultural diversities, mainly if people are located in another country (that includes national holidays, language, tools and services availability, communication barriers, and even religion\*);
* Distributed teams usually have their daily agenda ground rules and may be difficult to establish good communication with;
* Various communication challenges. It includes meetings and integrations, alignment with business objectives, and sustainable development pace.
## \*Holidays
### Ukraine
| **DATE** | **NAME** |
| ---| --- |
| 1 January | New Year's Day |
| 7 January | Orthodox Christmas Day |
| 8 March | International Women's Day |
| April (varies) | Orthodox Easter Day |
| 1 May | Labor Day |
| 9 May | Victory Day |
| June (varies) | Orthodox Pentecost |
| 28 June | Constitution Day |
| 24 August | Independence Day |
| 14 October | Day of Defenders of Ukraine |
| 25 December | Catholic Christmas Day |
### USA
| **DATE** | **NAME** |
| ---| --- |
| 1 January | New Year's Day |
| 3rd Monday in January | Martin Luther King Jr. Day |
| 3rd Monday in February | Presidents' Day |
| Last Monday in May | Memorial Day |
| 19 June | Juneteenth |
| 4 July | Independence Day |
| 1st Monday in September | Labor Day |
| 2nd Monday in October | Columbus Day |
| 11 November | Veterans Day |
| 4th Thursday in November | Thanksgiving Day |
| 25 December | Christmas Day |
### UK
| **DATE** | **NAME** |
| ---| --- |
| 1 January | New Year's Day |
| April (varies) | Good Friday |
| May (varies) | Early May Bank Holiday |
| June (varies) | Spring Bank Holiday |
| June (varies) | Queen's Platinum Jubilee |
| August (varies) | Summer Bank Holiday |
| 25 December | Christmas Day |
| 26 December | Boxing Day |
# Resolving the challenges
## Time zone challenge
Even with significant time zone differences, ensure there are at least **two-three hours** of overlap every day to keep things in sync. When all team members are available online, use this overlapping time to schedule team meetings or discussions and keep everyone in the loop.
Create a plan of how long team members can take to respond to an email or message. This way, no request or query will go unattended for long, and the employees won't feel they have to respond to every message immediately. It is similar to how we do the **SLA** for support.
One of the project manager's duties is to acknowledge the team with [time zone differences](https://www.worldtimebuddy.com/).
## Cultural Challenge
Avoid using any slang or colloquialisms when you communicate with your team members. Avoid using any culture-specific references in your team communication channels that everyone may not be familiar with. Using vague references doesn’t just make it difficult for team members to understand the context of a message, but it can also make them feel left out.
Also, mind the national holidays when creating a roadmap with deliverables.
## Tools and Services challenge
While most areas in the world have internet coverage, there is a probability of poor connection due to internet speed limits and certain tools in specific countries (e.g., ZOOM, Github are partially working in China, Slack is not working in Cuba). Thus, one must plan workarounds which are usually extra costs.
Agile charter may contain the project ground rules explicitly tailored for distributed teams instead of just one team in one place.
## Sync Challenge
Having someone take on a **facilitation role** at each location to improve engagement and participation helps to improve overall results. It could be someone to not only represent a team but rather advocate its challenges, primarily the Scrum Master. Those people may form an integration Team similar to what one can see in any scaled agile framework (Nexus, SoS, LeSS).
## Communication challenge
To resolve the communication challenge, one must have:
* a clear workflow and reporting to each other,
* regular synchronization based on the stakeholder management plan and regular video meetings,
* set up the development process, including:
* establishing access and sharing credentials,
* creating secure data transfer (VPN),
* code review,
* code integrations,
* merge requests management,
* establish knowledge sharing across teams,
* celebrate achievements together.
Ensure you avoid lengthy and pointless meetings that are only a waste of time. [One study by Atlassian](https://www.atlassian.com/time-wasting-at-work-infographic) showed that 91% of all meeting goers daydreamed during meetings, and 39% slept during meetings.
Based on the recommendations, here's a list of tools that might be useful:
* Team communication tool: Slack
* Video conference tool: Zoom
* Tool for managing complex projects: Jira
* Tool for managing simpler projects: Trello
* Tool for online signing: DocuSign
* App for storing files and documents: MS Office
* Software development tool: GitLab
# Contractors
General contractors often contract parts of their work to specialist contractors, who have the skills needed for other job areas. It may not only be the areas which Devcom currently does not develop eagerly or considers less profitable but augment existing ones, like development staff.
Contractors may act as individuals (freelancers) and companies. It imposes another term: subcontractor, a person working for the company Devcom has a contract with.
## **Step 1: Interview the vendor and determine your needs**
Hiring contractors is almost similar to the process of hiring in-house employees. The difference will be noted in the contract; often, these points will be working hours, rate, and the termination period notice. The employee lifecycle that was developed by HR is also applicable.
## **Step 2: Hire the right contractors**
It's important to remember that it's not necessarily true because someone claims to be an expert. Because the contractor we hire will represent Devcom, one should do due diligence before asking them to start the actual job. It's also essential to get a good idea of their work ethic and ensure contractors' plans for the job match the project's expectations.
## **Step 3: Create a contract to nail down the specifics**
Nevertheless, knowing your and/or the company's obligations is also essential. And this goes beyond the contracted amount of compensation. It is exactly the sweet spot where the devil is in the details.
It is always two-way communication that requires supervision and regular feedback when fulfilling the conditions of the contract. It can be as follows:
* formal buy-in procedures;
* sign off of interim deliverables;
* acceptance of completed work.
Please contact the Financial Department to create the contract for contractors.
## **Step 4: Manage the contractor and maintain a relationship**
After the agreement/contract is signed, it is valuable to have the person responsible on the Devcom side manage this type of labor procurement.
Contractors/sub-contractors will be part of the team; thus, they must obey all project procedures, follow the rules (Agile charter), and work cohesively on its objectives. Typically, the operational part is managed by a project manager or other direct supervisors (e.g., Tech Lead):
* A person goes through the onboarding process;
* Devcom's corporate email is assigned;
* Time is being reported to DCM;
* Contractors do not have [default benefits](https://sites.google.com/devcom.com/dcintranet/corporate-stuff/social-package?authuser=0);
* On-demand requests and specific tools (hardware, online services, security-related accounts, other sensitive information) must be approved by AM.
# Estimation Techniques
[Ukrainian version of this guideline](https://docs.google.com/document/d/16GXRMTywUJEVOuNGHAYWcTpwPXrHYG-1wjqr0-z9kvY/edit?usp=share_link)
# Estimates in Story Points
Estimates in story points are tricky for those who have never used these relative measurements. However, it keeps estimation steady regardless of team size. A team commits to less work or takes more depending on team scaling.
**Classic Scrum size of each card is as follows**: 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞, ?
For convenience, one may use online tools to do the estimation in story points.
One of the classic approaches is [Poker Planning](https://www.planitpoker.com/) for user stories or tasks as they are “equal“ in terms of sizing. Further breaking them down into sub-tasks is part of Sprint planning.
A mix of the Fibonacci sequence is used to simplify estimation.
The comparison below can **ONLY** be used as an example to think about story points relative to absolute units!
| **STORY POINTS** | **ABSOLUTE ESTIMATES (h)** |
| ---| --- |
| **1/2** | 1-2h |
| **1** | 1/2d (4h) |
| **2** | 1d (8h) |
| **3** | 2d (16h) |
| **5** | 3d (24h) |
| **8** | 4d - 5d (32h - 40h) |
| **13** | 7d (56h) |
| **20** | 10d (80h) |
| **40** | 20d (160h) |
| **100** | 50d (400h) |
| **∞** | Too large item, hard to estimate |
| **?** | Unknown due to lack of clarity |
|  | Time to take a break |
Teams consider only how much effort a product backlog item will require relative to other items.
More about story points you may read on the [Scrum.org](https://www.scrum.org/resources/blog/why-do-we-use-story-points-estimating) site.
# Estimates Of T-Shirt Sizes
**T-Shirt** sizes do not provide precise estimates since they are also relative measurement points. To get an idea of how big is a story/task, one has to establish it before the evaluation session. It is quite effective during the Refinement/Grooming meetings when a Product Owner needs a rough estimate.
One may consider the following relations of points when thinking of the **T-Shirt** size:
* **S** (1-3)
* **M** (5-8)
* **L** (13-21)
* **XL** (40-100)
# Other Estimations Techniques
## **Expert opinion**
This approach is valid only if the details are known and the experts are familiar with the domain and have experience. For better results, it would be beneficial to decompose big tasks. **Delphi** technique is somewhat similar.
**Analogous** estimating uses expert judgement and historical information and is similar to **Expert opinion** but doesn’t require domain experts to be involved.
## Three-point estimate
This approach is often used when providing high-level estimates during the presales. However, it can be applied to estimate tasks of an ongoing project.
Risks must be identified and known to everyone involved in the estimation.
The simple average of the three-point estimates can be calculated as follows:
**(P+O+M)/3**, where M - most likable time, P - pessimistic, and O - optimistic, including the risks and can consider as something unknown.
Also, another formula derived from the **Program Evaluation Review Technique** (**PERT)** can calculate the weighted average:
**(P+4M+O)/6**
Activity standard deviation is the possible range for the estimates and calculated as:
**(P-O)/6**
By default, the estimation is done in hours using the template.
[https://docs.google.com/spreadsheets/d/1Bly-8fES\_aALxBKp6WnfSTrKXQ69C9fBlCPjYnC89GE/edit?usp=sharing](https://docs.google.com/spreadsheets/d/1Bly-8fES_aALxBKp6WnfSTrKXQ69C9fBlCPjYnC89GE/edit?usp=sharing)
# Tips
1. Do not overestimate.
2. Plan less, deliver more.
3. Estimates are the assumptions of knowns (design, integration) and unknowns (uncertainty, risks).
4. Divide tasks into smaller & manageable pieces.
5. Use [Velocity range calculator](https://www.mountaingoatsoftware.com/tools/velocity-range-calculator).
6. Consider other's work & dependencies during estimation.
7. Standardize the feature requirements template and process.
8. Involve everyone who can contribute.
# Feedback
[Ukrainian version of this guideline](https://docs.google.com/document/d/1cGOUz5DJtQZqMbIWVJ0YiqtYvKbNUlBFO1BFiz93B8A/edit?usp=share_link)
# Feedback From Sprint Review
Sprint Review is useful to provide a snapshot of the state of the Product as a whole. With multiple teams contributing during the Sprint, not everything done can realistically be reviewed. It’s not just about the demonstration.
The Sprint Review is timeboxed to four hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
A feedback process is an essential part of agile product development. The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. This is a chance to show what was achieved and get feedback from stakeholders and other interested parties, broadly share information, and learn.
The feedback from the Sprint Review results in the Product Owner making adjustments to the Product itself and the Product Backlog:
* New items are added;
* Current tasks are amended with new information;
* Items become deprecated;
* Items are done/fixed/rewritten/completed within another scope;
* Obsolete items are removed
* The Product Backlog is transparent, visible, and understood.
The feedback on Sprint items can also be received during the 'mini reviews' during the Sprint. This allows us to hold an effective Sprint review in the end rather than turning it into a 'movie-like' demonstration.
# Random Feedback
Whenever feedback is received _(regardless of the event and source)_ from stakeholders in any manner (verbally or in written form), it might be registered in the issue tracking system.
Feedback sources are but are not limited to:
* **Email**
* Simply from a thread, where it is asked to make changes
* In the case of using Jira, one sends an email to jira@**_subdomain_**.atlassian.net:
* Put in CC a person who will be assigned (email used for Jira accounts)
* The email's subject becomes an issue summary (title) and
* The message (email's body) becomes a description. Other fields may become configurable in the future
* In the case of using **ZenDesk,** one creates an issue using the installed plugin to have real-time sync
* **Messengers**
* Requests of various kinds must be replied
* Reports of any kind must also be commented on other than a submitter
Whoever is receiving feedback must create a ticket or delegate it. A response back is required to notify a reporter that the issue is being accepted and processed
# Criteria
It is highly recommended to highlight at least:
* What is the purpose?
* What is the priority?
* Has this already been approved by key stakeholders?
* What category is this related to? (a task, bug, suggestion, or improvement)
# Next steps
Depending on **priority** and **urgency,** it is executed accordingly: either in the current or future working period (Sprint). A ticket appears either in the Product backlog or documented using other tools (e.g., Confluence, Google docs).
The artifacts above are reconciled with the Product Owner so that we are aware of what items must be taken care of first.
Note that not all feedback info will be transformed into issues. Some are just for discussion to update existing tasks or ignore if they violate the implemented business logic.
# Afterword
Don’t hesitate to ask for details if such are missing, vague or they are ambiguous.
# Knowledge Sharing
TEXT in **_bold_** **_italic orange (_****_including links in_** **_light blue_****_)_** is meant to be adopted by each project.
# **Guideline**
Knowledge sharing process means exchanging employees' knowledge, skills, and experiences. It ensures that the knowledge within an organization is available for employees whenever they need it, and its benefits include retaining intellectual assets and improving productivity.
1. Knowledge sharing occurs every **_Thursday at 9:30 AM local time (2:30 AM EST)._**
2. Volunteers or assigned speakers should prepare the topic for discussion and plan the date.
3. Knowledge sharing sessions should be recorded for future reference (use Zoom, Skype)
| **DATE** | **SPEAKER** | **SUBJECT** | **TAKEAWAYS/ACTION ITEMS/COMMENTS** |
| ---| ---| ---| --- |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
# Meetings Flow
Meetings are events that tend to shed light on open questions and be on the same page when making decisions.
**NOTE:** One must participate only if one can contribute or have a question to ask; otherwise, you represent a Team.
If the time frame does not suit your calendar, please notify in advance via means of communication and offer an alternative time slot or solution.
By failing to prepare, you are preparing to fail. There’s nothing worse than showing up to a meeting with people who have not taken the time to prepare for it. Make sure to avoid losing face by planning any type of meeting.
# Each Meeting Has An Agenda
* Items to discuss are listed.
* Add additional info and attachments for better collaboration and review before the meeting day.
* Participants should prepare any questions a day before so that they can be addressed properly.
* Define participants who can contribute.
* Action items are meeting outcomes (responsible person and deadline if applicable).
| **ACTION ITEMS** | **URGENCY** | **DEADLINE** | **ASSIGNEE** |
| ---| ---| ---| --- |
|
| | | |
|
| | | |
* _Optional:_
* _Notify other people that they may be invited if needed so that they can plan their schedules accordingly_
* _Feel free to involve any teammates if they can contribute_
* _If you feel your presence is not required, ask an organizer to skip the meeting._
# Example
### **For daily meetings with the Client at 3:30 p.m. UA / 8:30 a.m. EST**
* Participate only if you can contribute or have a question to ask
* Stay around to catch up if needed
* These meetings are designed to discuss
* the Support tasks and
* any major changes (Environments, processes)
* urgent questions
* sprint pulse:
* Any delays or blockers
* Ad-hoc requests
* People availability - vacations, sick leave, unexpected time off
| **ACTION ITEMS** | **URGENCY** | **DEADLINE** | **ASSIGNEE** |
| ---| ---| ---| --- |
|
| Medium | 06/28/2022 | Don Joe |
|
| High | Today | John Doe |
# Nexus Guide
[Ukrainian version of this guideline](https://docs.google.com/document/d/10R1JiGU24fWGftB-qbP4uDjMXv_zAT-IPuZP5ZunL2g/edit?usp=share_link)
Product delivery is complex, and integrating product development work into a valuable product requires coordinating many diverse activities. **Nexus** is a framework for developing and sustaining scaled product delivery initiatives. It builds upon Scrum, extending it only where necessary to minimize and manage dependencies between multiple Scrum Teams while promoting empiricism and Scrum Values.
The Nexus framework inherits the purpose and intent of the Scrum framework, as documented in the [Scrum Guide](http://www.scrumguides.org.). Scaled Scrum is still Scrum. Nexus does not change the core design or ideas of Scrum, leave out elements, or negate the rules of Scrum. Doing so covers up problems and limits the benefits of Scrum, potentially even rendering it useless.
# The Nexus Framework
Nexus extends Scrum in the following ways:
* **Accountabilities**: The Nexus Integration Team ensures that the Nexus delivers a valuable, useful Integrated Increment at least once every Sprint. The Nexus Integration Team consists of the Product Owner, a Scrum Master, and Nexus Integration Team Members.
* **Events**: Events are appended to, placed around, or replaced with regular Scrum events to augment them. As modified, they serve the overall effort of all Scrum Teams in the Nexus and each team. A Nexus Sprint Goal is the objective for the Sprint.
* **Artifacts**: All Scrum Teams use the same single Product Backlog. As the Product Backlog items are refined and made ready, indicators of which team will most likely do the work inside a Sprint are made transparent. A Nexus Sprint Backlog exists to assist with transparency during the Sprint. The Integrated Increment represents the current sum of all integrated work completed by a Nexus.
Figure 1: The Nexus Framework
# Nexus Integration Team
The Nexus Integration Team is accountable for ensuring that a done Integrated Increment (the combined work completed by a Nexus) is produced at least once a Sprint. It provides the focus that makes possible the accountability of multiple Scrum Teams to come together to create valuable, useful Increments, as prescribed in Scrum.
The Nexus Integration Team consists of:
* **The Product Owner:** A Nexus works off a single Product Backlog, and as described in Scrum, a Product Backlog has a single Product Owner who has the final say on its contents. The Product Owner is accountable for maximizing the product's value and the work performed and integrated by the Scrum Teams in a Nexus. The Product Owner is also accountable for effective Product Backlog management. How this is done may vary widely across organizations, Nexuses, Scrum Teams, and individuals.
* **A Scrum Master:** The Scrum Master in the Nexus Integration Team is accountable for ensuring the Nexus framework is understood and enacted as described in the Nexus Guide. This Scrum Master may also be a Scrum Master in one or more of the Scrum Teams in the Nexus.
* **One or more Nexus Integration Team Members:** The Nexus Integration Team often consists of Scrum Team members who help the Scrum Teams to adopt tools and practices that contribute to the Scrum Teams’ ability to deliver a valuable and useful Integrated Increment that frequently meets the Definition of Done.
# Nexus Events
Nexus events consist of:
* **The Sprint**
* _A Sprint in Nexus is the same as in Scrum. The Scrum Teams in a Nexus produce a single Integrated Increment._
* **Cross-Team Refinement**
* _Cross-Team Refinement of the Product Backlog reduces or eliminates cross-team dependencies within a Nexus._
* **Nexus Sprint Planning**
* _The purpose of Nexus Sprint Planning is to coordinate the activities of all Scrum Teams within a Nexus for a single Sprint._
* **Nexus Daily Scrum**
* _The Nexus Daily Scrum aims to identify any integration issues and inspect progress toward the Nexus Sprint Goal._
* **Nexus Sprint Review**
* _The Nexus Sprint Review is held at the end of the Sprint to provide feedback on the done Integrated Increment that the Nexus has built over the Sprint and determine future adaptations._
* **Nexus Sprint Retrospective**
* _The Nexus Sprint Retrospective aims to plan ways to increase quality and effectiveness across the whole Nexus._
# Nexus Artifacts And Commitments
Artifacts represent work or value and are designed to maximize transparency, as described in the Scrum Guide. The Nexus Integration Team works with the Scrum Teams within a Nexus to ensure that transparency is achieved across all artifacts and that the state of the Integrated Increment is widely understood.
### Product Backlog
A single Product Backlog contains a list of what is needed to improve the product for the entire Nexus and all of its Scrum Teams.
#### Commitment: Product Goal
### Nexus Sprint Backlog
A Nexus Sprint Backlog is the composite of the Nexus Sprint Goal and Product Backlog items from the Sprint Backlogs of the individual Scrum Teams.
#### Commitment: Nexus Sprint Goal
### Integrated Increment
The Integrated Increment represents the current sum of all integrated work completed by a Nexus toward the Product Goal.
#### Commitment: Definition of Done
Extended information can be found in [Online Nexus Guide](https://www.scrum.org/resources/online-nexus-guide) or at [DevCom's seminar](https://sites.google.com/devcom.com/dcintranet/devcom-talks/non-tech-talks#h.lxut3zlco4ho).
# Whitepapers
* [Framework Overview](https://scrumorg-website-prod.s3.amazonaws.com/drupal/2018-10/NexusOverview-A4.pdf)
* [An Introduction to the Nexus™ Framework](https://scrumorg-website-prod.s3.amazonaws.com/drupal/2016-06/An%20Introduction%20to%20the%20Nexus%20Framework%20-%20June%202016_0.pdf)
* [The Nexus Integration Team](https://scrumorg-website-prod.s3.amazonaws.com/drupal/2016-11/The%20Nexus%20Integration%20Team.pdf)
* [The Nexus Daily Scrum](https://scrumorg-website-prod.s3.amazonaws.com/drupal/2016-10/They%20Thought%20It%20Was%20Overkill%20-%20The%20Nexus%20Daily%20Scrum%20Whitepaper.pdf)
* [Cross-Team Refinement in Nexus](https://scrumorg-website-prod.s3.amazonaws.com/drupal/2016-08/Cross-Team%20Refinement%20in%20Nexus%20whitepaper_0.pdf)
# Books
* [Nexus Framework](https://drive.google.com/file/d/1nDGMOm-Y3CRBgQrfrKj2cCyQDgen-4n_/view?usp=sharing)
# OKR (Guidelines)
# Guideline
“A management methodology that helps to ensure that the company focuses efforts on the same important issues throughout the organization.”
An **OBJECTIVE** is simply WHAT is to be achieved, no more and no less. **KEY RESULTS** benchmark and monitor HOW we get to the objective.
The higher the goals, the higher the performance.
OKRs are not islands. On the contrary, they create networks - vertical, horizontal, and diagonal.
By deepening people’s sense of ownership, bottom-up OKRs foster engagement and innovation.
From CEO to the manager, all OKRs must be transparent.
If KRs include words like “consult,” “help,” “analyze,” or “participate,” they describe activities. Instead, describe the end-user impact of these activities. The evidence must be available, credible, and easily discoverable. Examples of evidence include change lists, links to docs, notes, and published metrics reports.
**Objectives** are the “Whats.” They:
* express goals and intents;
* are aggressive yet realistic;
* must be tangible, objective, and unambiguous; it should be obvious to a rational observer whether an objective has been achieved.
* The successful achievement of an objective must provide clear value for the company.
**Key Results** are the “Hows.” They:
* express measurable milestones which, if achieved, will advance objective(s) in a useful manner to their constituents;
* must describe outcomes, not activities;
* must include evidence of completion.
# OKR Types
OKRs have two variants, and it is important to differentiate between them:
* **Commitments** are OKRs that we agree will be achieved, and we will be willing to adjust schedules and resources to ensure they are delivered.
* By contrast, **aspirational** OKRs express how we’d like the world to look, even though we have no clear idea how to get there and/or the resources necessary to deliver the OKR.
# OKR Scoring
* 0.7 to 1.0 = Green (We delivered)
* 0.4 to 0.6 = Yellow (We made progress but fell short of completion)
* 0.0 to 0.3 = Red (We failed to make real progress)
Self-assessments must be as guides, not as grades.
**Continue**: If a green zone (“on track”) goal isn’t broken, don’t fix it.
**Update**: Modify a yellow zone (“needs attention”) key result or objective to respond to changes in the workflow or external environment. What could be done differently to get the goal on track? Does it need a revised timeline? Do we back-burner other initiatives to free up resources for this one?
**Start**: Launch a new OKR mid-cycle whenever the need arises.
**Stop**: When a red zone (“at-risk”) goal has outlived its usefulness, the best solution may be to drop it.
# Working with OKR
Please see the [presentation](https://docs.google.com/presentation/d/1AR2LTe4Mo4ME1usiL9rWYtNi_sYX0fvdhMj17fadbbM/edit?usp=sharing) with OKR & Wardley Mapping tool.
# OKR Template
[https://docs.google.com/spreadsheets/d/15WQ4jB5TJgVz3rm9Lz61pLCL8d40RxpznOHg-r4nCZA/edit#gid=772012497](https://docs.google.com/spreadsheets/d/15WQ4jB5TJgVz3rm9Lz61pLCL8d40RxpznOHg-r4nCZA/edit#gid=772012497)
# Resources
[Measure What Matters](https://drive.google.com/file/d/1WjDzLI5IZjJsrd02Va_bKHIkfoG7oIg4/view?usp=sharing)
# Project Requirements (Guidelines)
[Ukrainian version of this guideline](https://docs.google.com/document/d/1aN7sYxVdbqj7a0Yg0zAR4FJQ9h7fs296ytyuSHmSi10/edit?usp=share_link)
[Requirements Management Plan](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7062) is an essential part of any project. It encompasses various types of information, including a management approach.
Find the [**Template here**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5361)
TEXT in **_bold_** **_italic orange (_****_including links in_** **_light blue_****_)_** is meant to be adopted by each project.
# Guideline
The end goal of all meetings and discussions around new functionalities is to create and size tasks for better planning (**Definition of Ready** for documentation). The steps to be taken are quite simple to follow.
### **Draft** → Requirements Done → Ready For Sizing → Completed
1. **Product Owner** (PO) brings to the table the idea generated by the business need.
1. **PO** transforms the idea into a requirement doc (**DRAFT** specification)
2. **PO** starts to create tasks/user stories and/or Epics.
2. After the **DRAFT** of the specification is completed, it must be discussed with the **Tech Leads**.
1. A meeting is being held to originally explain the feature and make sure **REQUIREMENTS DONE.**
2. Questions & Answers (Q&A) sessions can be held during the same meeting or separately to make sure the specification is **READY FOR SIZING** and artifacts (Epics/user stories/tasks) are amended if exist.
3. The assigned person (Tech Leads, Business Analyst, Project Manager, and preferably **PO**) creates a list of user stories to be evaluated in T-Shirt sizes or story points/hours.
1. Stories/Tasks are listed within the same document with attributes such as
1. description
2. acceptance criteria and constraints
3. other notes and attachments that bring clarity
2. Stories are discussed and then sized depending on the level of details. Only then the requirements as a specification are **COMPLETED**.
4. These Epics/stories/tasks are then prioritized by **PO** and added to a task-tracking system.
1. They are available for Sprint planning regardless if it is done by Integration Team (scaled Scrum) or an individual team.
2. Further breaking down into tasks (UI, front-end, back-end, testing) is performed during the planning meeting.
# Statuses
**DRAFT** \- the initial requirements that need to be shaped by the Product Owner.
**REQUIREMENTS DONE** - the requirement document is completed from the Product Owner's perspective.
**READY FOR SIZING** - all questions are being cleared, and stories in a document are ready to be discussed and estimated.
**QUESTIONS** \- there are open questions to the Product Owner and blockers.
**COMPLETED** \- the specification is evaluated, and tasks are created in Jira.
# Tasks Flow
For successful delivery in an agile environment, use the confirmation questions to ensure the alignment with business objectives and expectations:
* Will we release during this period? Ideally, how often? Perhaps even on what date?
* What will be fully developed and delivered?
* What will be developed enough that a subset of it can deliver?
* What other deliverables are needed? Are there documents that must be updated?
* What quality level is expected? Is the project successful, for example, if the deadline is met, but some low-priority tasks are cut off?
## Jira tasks flow
Find the sample of the task flow in Jira, a task management system by Atlassian.
[]()
# Project Closure (Guidelines)
[Ukrainian version of this guideline](https://docs.google.com/document/d/1a98e9-EPXgnJwJhFd-1-MPYx0W2OFlqWpYI7_hqwtzc/edit?usp=share_link)
Project closure is a written confirmation that all the involved parties approved the completed project or phase. Effectively, they agree that the project has been kept on track and that the expectations of all of its stakeholders have been met.
Find the [**Template here**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7362)
# Guideline
Once the project or phase has been finalized and before the celebrations start, you need to formally round things off by moving into the closure process.
Closure refers to completing all tasks and terms that are mentioned as deliverable and outstanding upon the initial drafting of the agreement.
It must be reviewed and approved by the project manager, sponsor, and relevant stakeholders. The document should summarize what the project accomplished and/or produced notable big wins or difficulties and post-project issues or tasks that still need to be addressed.
In other words, Project Closing is the combination of the following when applied to a project:
1. Assurance that all the work has been completed.
2. Assurance that all agreed-upon project management processes have been executed.
3. Formal recognition of the completion of a project - everyone agrees that it is completed.
4. Making sure all the work that needed to be done had been done.
5. Obtaining approval from the project's sponsor and customer (whether internal or external) for the work completed.
6. Reviewing whether or not all organizational governance processes have been executed.
7. Assessing whether or not the necessary project management processes have been applied.
8. Administrative closing of any and all procurements, reviewing that all work on the contract has been completed and that both parties have completed their contractual obligations toward each other.
9. Formally recognizing the completion of a project and its transition to operations.
10. Validating that the project achieved the benefits identified in the business case.
11. Capturing of lessons learned: What was done well and should be documented to be repeated in the future? What could have been done better? And if so, how could it have been done better?
12. Disbanding project resources, freeing them to perform other projects and undertake other tasks as required within the organization. Use DCM as well to set the end date and reassign team members.
13. Transitioning project deliverables to the customer organization in a manner that warrants seamless operations and support.
# Project Contract Types
# Guideline
Regardless of the type, any project starts with analyzing the Client's business need and making an offer. Let's see how this is typically executed.
After the Client's engagement, he may want to sign [NDA](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4061) with Devcom first. Usually, this will be done by CEO or AM and could be followed by [MSA](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4401).
**Time****line**: up to 5 days. After the dedicated AM gets the project, he shall perform a set of actions to start the ball rolling:
1. He assigns a project manager or acts on his behalf. **Time****line**: up to 2 days if resources are available.
1. AM can assign himself
2. AM can [assign PM and delegate](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-6308?block=block-2295ae55-d5d1-42fc-88b4-c1182faf5827) his responsibilities.
2. AM involves BA/PM ([through the service ordering](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-6308?block=block-2295ae55-d5d1-42fc-88b4-c1182faf5827)) to collect requirements and define the primary business need, measurable project goals, constraints, and assumptions. Further, BA's work relates to the [requirements-gathering](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7062) process. **Time****line**: up to 3 days.
1. Depending on the requirements, governance, and Client demands, AM and PM have to pick the suitable cooperation model, which impacts all other processes starting at the project planning phase. **Time****line**: up to 2 days. There are three of them Devcom currently works with:
1. **Fixed price contract**
2. **Time & material**
3. **Monthly budget contract**
3. Together with Tech Lead, AM defines the technology stack with further CTO approval. **Timeline**: up to 3 days.
4. AM or Project Administrator starts a project in DCM with available information. One shall hold the [internal meeting](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-9568) (internal kick-off) to inform the people involved. **Timeline**: up to 1 day.
5. AM, with a PM and Tech Lead, plans the preliminary team composition based on the known scope and balances people's levels of expertise so that the project is profitable and there is enough room for self-development. **Timeline**: up to 2 days.
6. PM defines how to track project progress using various metrics. **Timeline**: up to 1 day.
7. AM, PM, BA, and Tech Lead conduct an overall initial risk analysis related to the primary business need. **Time****line**: up to 2 days.
8. PM gathers and prepares the information about how the project will look like: approach, methodology, and roles, and uses the [guide](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-6428?block=block-6cb61d3a-f95a-4d9c-81ac-026103c75a3d) to choose the right tools. **Time****line**: up to 3 days.
* Communication
* Stakeholder management
* Documentation
* Task management
* There may be other tools the team needs access to before the start. Think of tech design, databases, and UI artifacts like fonts, style guides, and logins.
The steps above may be part of the [Discovery phase](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4441).
AM or PM [use the template](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-10240) and hold the [kick-off](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7502) meeting to wrap up the abovementioned information.
The goal of every project is to get financial, social, or other types of benefits. Thus all stakeholders strive to spend the minimum time, effort, and resources to get the working product or service. We call it the **minimum viable product** (MVP).
After the scope of MVP was planned, AM and PM had to control the scope and budget very precisely. Regardless of the cooperation model, he acts accordingly:
* Monitors the scope completion progress
* Monitors the budget usage.
One must avoid the situation when 80% of the budget produced less than 50% of the planned outcome. It is recommended to chunk the scope and budget into four even pieces and monitor the execution to shift one or more variables in the project management triangle.
# Fixed Price Project
A fixed-price type of project guarantees a fixed budget regardless of the time and cost. These are the main advantages for a Client. Thus, this approach is most suitable for projects with a strictly defined scope of tasks where the requirements do not change much.
The advantages of a fixed price model:
* The requirements are well-planned and transparent;
* The budget and terms are known, and most changes are foreseen;
* The risk is low for a Client due to the precise planning phase;
* The deliverables have strict deadlines;
* The most suitable are small projects, including some consulting services;
* The vendor (Devcom) knows the expected profitability.
## Approach
A fixed amount of resources requires precise planning, which imposes the classic [Waterfall](http://tryqa.com/what-is-waterfall-model-advantages-disadvantages-and-when-to-use-it/) approach that suits the best fixed-price contracts. However, it is still recommended to understand [risk management](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7022) principles and expect [changes](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4241) due to high market competition. Also, PM and AM may agree to use [Agile practices](https://docs.google.com/spreadsheets/d/1ydsJ2BeB8XXfOowgDOXStAldx3SQMGH2mIJp3z_LxRU/edit#gid=0) during the project execution.
The [periodical review](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4381) takes place as well at each stage and has its deliverables:
* Analysis
* Requirements specification
* Design
* Development
* Testing
* Deployment
* Maintenance & support
The essential artifact in **Fixed Price** projects is fixed scope. If it tends to change, PM must document that change order, reassess the potential change with all relevant stakeholders, and begin with the initial steps according to SDLC.
## Metrics
By default, the estimation of total work is performed in hours. The KPIs which fit the waterfall are the following:
* **Earned value**, the evaluation of actually delivered scope respectively to all planned project scope;
* [**Cost variance**](https://www.brighthubpm.com/monitoring-projects/57942-examples-of-cost-variance-cv-and-schedule-variance-sv-in-a-project/) is the completed work cost (earned value) compared to the actual cost.
* [**Cost performance index**](https://www.pmlearningsolutions.com/blog/cost-variance-versus-cost-performance-index-pmp-concept-39) is the ratio of the earned value to the actual cost.
* [**Schedule variance**](https://www.brighthubpm.com/monitoring-projects/57942-examples-of-cost-variance-cv-and-schedule-variance-sv-in-a-project/) is the completed work when compared to the planned schedule.
* [**Schedule performance**](https://www.pmlearningsolutions.com/blog/schedule-variance-versus-schedule-performance-index-pmp-concept-40) [](https://www.pmlearningsolutions.com/blog/schedule-variance-versus-schedule-performance-index-pmp-concept-40)[**index**](https://www.pmlearningsolutions.com/blog/schedule-variance-versus-schedule-performance-index-pmp-concept-40) is a ratio of the earned value to the planned value.
* [**Estimate at completion**](https://www.pmlearningsolutions.com/blog/budget-completion-versus-variance-completion-pmp-concept-42) is the total anticipated and budgeted spending for a project based on the project estimates and assumptions.
* [**Estimate to complete**](https://www.pmlearningsolutions.com/blog/estimate-completion-versus-estimate-complete-pmp-concept-41) is a forecast of how much more money will need to be spent to complete the project.
* [Other metrics](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4361) are used to track quality and other essential project areas. Some Agile metrics are convenient as well.
## Documentation & Templates
The documents are required to keep agreements formal and transparent. They include different items depending on the [project stage](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3821?block=block-7d4fd0c2-3de9-491b-8348-79dce234a4e6):
* Initiation
* Planning
* Execution
* Monitoring and control
* Closure
A Gantt chart is one of the most valuable tools to represent visual progress.
Each stage or project must be properly [closed](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7322) with subsequent resources released. AM hands over all artifacts, and a Client must sign off all deliverables.
# Time & Material Project
The time & material (T&M) type of project pays the vendor for the work hours needed to complete a project. A Client may be aware of all the team's resources and efforts and share risks related to work scope. Ultimately, he is billed for the actual time spent on development (which usually includes design, testing, management, and support).
The advantages of a time & material model:
* The requirements are pretty flexible and can be added or removed almost instantly;
* A Client knows the hourly rate and can control the expenses based on business needs;
* The transparent processes allow for monitoring the progress depending on the reported deliverables;
* The most suitable for startups, long-term projects, and dynamic projects, including some consulting services;
* The vendor (Devcom) controls the expenses based on the profitability goal.
## Approach
The elements of unknown and rapid changes impact the resources needed; thus, precise planning is achievable in the short term. Any Agile approach would be better for the Time & Materials projects. However, it is still recommended to maintain the minimum documentation and understand the [risk management](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7022) principles.
Since the high frequency of [changes](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4241) is expected due to huge market competition or other factors, the chosen Agile framework may be either purely adapted or upgraded with [other practices](https://docs.google.com/spreadsheets/d/1ydsJ2BeB8XXfOowgDOXStAldx3SQMGH2mIJp3z_LxRU/edit#gid=0).
When it comes to the planning phase, one must understand the high-level roadmap and align the business's milestones with iterative management activities.
The essential practices are defined as such:
* The [planning phase](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4001) is executed during intervals called 'sprints'.
* It is highly recommended to hold [refinement](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5361) activities and [forecast the scope](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3881) to have enough information for planning.
* The progress is tracked using daily standups and metrics (story points burndown).
* The [periodical reviews](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4381) occur at the end of the sprints, and a team may demonstrate the [completed tasks](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5341).
* A team discusses the action items for continuous improvement [after each iteration](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5421).
The essential process in **T&M** projects is to monitor the budget. The main reasons for this are a few conditions so that the Client is not astounded by high numbers in the invoice.
1. **Fixed number of hours** for a certain activity (e.g., support). It is recommended to provide regular updates on how much is left to amend the scope or budget if needed.
2. **Average tasks flow**, activities that do not exceed a predefined amount in estimates do not require the Client's approval. It allows for avoiding overcontrol and working together on new large features to assess the feasibility.
3. **Significant changes in scope**, where large features require greater efforts which, impose significant budget increases.
## Metrics
By default, the estimation of total work is performed in hours but using one of the Agile frameworks proves the story points effectiveness. The KPIs which fit the Agile can vary:
* Scrum
* Velocity
* Epic/release/sprint/product burndown
* Sprint goal success
* Kanban
* Cycle time
* Lead time
* Lean
* Takt time
* Lead time
* Cycle time
* [Other metrics](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4361) track quality-related defects, deployment frequency, financial project status, and even [team satisfaction](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-9201).
## Documentation & Templates
The Agile approach suggests having 'just enough documentation' at a certain point, but it must be present to [keep agreements formal](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3841) and transparent. They include different items depending on the [project stage](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3821?block=block-7d4fd0c2-3de9-491b-8348-79dce234a4e6) and necessity.
# Monthly Budget Project
A monthly budget type of project mixes the fixed price and time & material projects. The budget has its upper limit per phase or iteration (e.g., month, sprint). The vendor may cover the additional costs outlay.
The advantages of a 'monthly budget' model:
* The project is complicated but requires maximum flexibility;
* The requirements are defined only at each project phase;
* The most suitable for long-term dynamic projects which are business-driven and market-oriented;
* The vendor (Devcom) controls the expenses based on the profitability goal.
The **Approach** and **Metrics** are similar to what is mentioned in the [Time & Materials model](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4281?block=block-c55abce7-2604-4f42-b202-7b8e58197376). There is one distinguishing metric every AM and PM must track constantly.
Fixed-budget projects have limited financial resources per period (month) or project stage.
This metric can be measured as:
* Comparison of available budget to the profitability target;
* Comparison of the full-time employees (FTE) a team can afford based on the budget to the current number of people.
The essential process of the monthly budget projects is constantly monitoring the progress. If a feature cannot be delivered as planned as it takes more effort and time, it must be reviewed with a Client.
There might be a few reasons for this:
* The functional analysis and design were not appropriately held and did not cover business need
* The new information portion was added, and/or stakeholders submitted additional requests.
Usually, it is up to the Client to decide whether to increase the monthly budget (temporarily or permanently) or just stretch the timeline because of scope creep.
# Scaled Teams Projects
As a team, people define themselves as a cross-functional group of up to 10 individuals who plan, build, test, and deliver value. Usually, it happens incrementally. Due to the communication complexity, it is better to have smaller teams than one team of 10 or more people.
The management of such teams requires the knowledge of working with multiple teams, integration approaches, and coordination of actions.
The PMO recommends utilizing proven Agile practices such as [Nexus](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5081), LeSS, SoS, and SAFe for uncertain projects and rapid changes in business requirements. There are additional events, artifacts, and documentation doesn't change much. All these scaled frameworks emphasize the integration part, where dependencies of every kind occur:
* A separate 'integration team';
* Additional meetings to review dependencies, blockers, and reflect on past events;
* Activities to plan a few iterations ahead to satisfy '[**Lean**](https://leanmethods.com/resources/articles/what-is-lean/)' principles.
Fixed-price projects impose longer planning when it comes to large teams. The classic project phases remain. Nevertheless, the integrations must also be controlled very precisely as changes of any kind impact the upcoming phases.
## Teams' Integration Activities
* Collaborate with a Client and/or other stakeholders to create and refine detailed requirements with clear acceptance criteria to match project objectives.
* Estimate scope at the integration level.
* Determine the base for the technical design within the agreed architectural guidelines.
* Create the automation where applicable to build continuous integration and delivery.
* Use the 'design first' approach to research, design, and prototype involving representatives from other teams.
* Deploy and integrate frequent changes in small batches to receive quick feedback from stakeholders depending on the environment.
# Consulting Services
Services provided by Devcom where the Fixed price model applies the best may include the following:
* Requirements analysis;
* BA consulting;
* UI/UX prototyping;
* Project tech review and report;
* Analysis of project management processes.
# Project Kick-off
[Ukrainian version of this guideline](https://docs.google.com/document/d/1eW7uzfbKZC6bP3ufhPOqos_cg4S-ajQsK84tGLv-E40/edit?usp=share_link)
The initial kick-off meeting sets the project's tone, style, and vision, establishes common goals, tasks, and timelines with the project team, builds trust, and promotes mutual understanding. There might be other meetings preceding as part of the project initiation phase.
Find the [**Template for the internal meeting here**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-9568)
For client work, the project kick-off meeting may include introducing the team working on the project, talking the Client through the project stages, agreeing on how to effectively work together to deliver value successfully, and setting the stage for a positive working relationship with the Client.
Smaller projects usually require one kick-off meeting.
In larger projects, this meeting is held when the planning is completed and execution is about to start. If the project is multiphase, a kick-off meeting may reoccur at the beginning of each phase.
These meetings serve differently for various stakeholders:
* Internal with the team to have it less formal and describe the upcoming processes' ground rules.
* External meetings impose the involvement of the Client's representatives to confirm expectations.
* The artifacts and style will be primarily the same.
* An agile kick-off meeting exists too. It also happens at the start. One can treat this as a starting point for **Sprint 0**, where the whole team plans and discusses their activities and how to use their skills to reach maximum value.
# Guideline
## Step 1: Pre-work
After the Client's engagement, he may want to sign [NDA](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4061) with Devcom first. Usually, this will be done by CEO or AM and could be followed by [MSA](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4401). After the dedicated AM gets the project, he shall perform a set of actions to start the ball rolling:
1. Assign a project manager or act on his behalf.
2. Involve BA/PM or acts on his behalf to gather requirements and define the primary business need, measurable project goals, constraints, and assumptions.
1. Depending on the requirements, governance, and Client demands, AM and PM have to pick the right [cooperation model](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4281), which impacts all further processes starting at the project planning phase.
3. Together with Tech Lead, AM defines the technology stack.
4. Start a project in DCM with available information. Use the [internal meeting](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-9568) to inform the people involved.
5. Plan the preliminary team composition based on the known scope and balance people's levels of expertise so that the project is profitable and there is enough room for self-development.
6. At a glance, define how to track project progress using various metrics.
7. Conduct overall initial risk analysis related to the primary business need.
8. Gather information about how the project will look like: methodologies, roles, and use the [guide](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-6428?block=block-6cb61d3a-f95a-4d9c-81ac-026103c75a3d) to choose the right tools for:
* Communication;
* Documentation;
* Task management.
* There may be other tools the team needs access to before starting. Think of tech design, databases, and UI artifacts like fonts, style guides, logins, and the correct details for invoicing.
Another right move is to put down all the available project information in a single place.
## Step 2: Prepare Artifacts
The output of the first step would be a prepared [SOW](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4041), initial versions of other documents, like [stakeholder management](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3721), a roadmap with objectives, [project charter](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4221), which has to be signed as the outcome of the meeting.
## Step 3: Project Kick-off Meeting Planning
A project kick-off meeting should not be an “information broadcast.” If there is a need to share background information in advance, the AM or PM can use the initial versions of the documents. Project kick-off meetings should actively involve the team and anyone else who’s a stakeholder or whose work will be affected by the project.
AM is responsible for organizing and facilitating the meeting;
* The date and time of the meeting are predefined and agreed upon, so everyone can make it to the meeting. Then send the invitations.
* Choose the right tool if it happens online (ZOOM, Slack, MS Teams).
* Facilitate the meeting and prepare meeting notes as a follow-up via email after that.
## Step 4: Project Kick-off Meeting
The essential items to cover in the agenda so that all participants are on the same page:
1. **Introduction**
1. _Let everyone introduce themselves, their role in the project, and what they will deliver._
2. **What is the main business case of the project?**
1. _Describe the challenge we are attempting to solve._
3. **What is the project known scope to date?**
1. _Statement of work, including resources, deliverables, requirements, and out-of-scope items._
4. **What is our vision and action plan?**
1. _High-level estimates, tech vision, management approach, team composition, phases, and tracking progress._
5. **Who is doing what?**
1. _Initial Stakeholder engagement plan._
6. **What does a successful project look like from the Client's perspective?**
1. _Objectives we must keep in mind to meet the Client's expectations._
7. **What else is worth announcing at this point?**
1. _Q&A session where remaining or arising questions are clarified._
### Tips
* Keep it brief;
* Do not delve too much into details;
* Make sure everyone is involved and make inputs;
* Prepare meeting notes and action items if needed.
# Project Management Handbook
# Guidelines
According to PMBOK 7th edition, **project management** is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements. Project management refers to guiding the project work to deliver the intended outcomes. Project teams can achieve the outcomes using various approaches (e.g., predictive, hybrid, and adaptive).
Let's see how existing PMO policies contribute to a value delivery system that works most effectively when information and feedback are shared consistently among all components, keeping the system aligned with strategy and attuned to the environment.
Every project starts with an idea or a need every person pursues. Then this person finds DevCom, where highly skilled professionals begin the breathtaking journey and assist with achieving objectives.
# Step 1. **Analysis & Presale**
Any project starts with analyzing the Client's business needs and making an offer. Let's see how this is typically executed.
After the Client's engagement, he may want to sign Private (https://app.clickup.com/8491693/docs/834nd-2241/834nd-4061) with DevСom first. Usually, this will be done by CEO or AM and could be followed by Private (https://app.clickup.com/8491693/docs/834nd-2241/834nd-4401).
After the dedicated AM gets the project, he shall perform a set of actions to start the ball rolling:
1. He assigns a project manager or acts on his behalf:
1. AM can assign himself
2. AM can assign PM through Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-6308](https://app.clickup.com/8491693/docs/834nd-2241/834nd-6308)) and [delegate his responsibilities](https://docs.google.com/document/d/1QhyBvrZuN67xaMPmNL-uAyiZgu6eDydjXXTgTgQHDb4/edit?usp=sharing).
2. AM involves BA/PM (through the service ordering) to organize and facilitate collaboration with stakeholders as per Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-3721](https://app.clickup.com/8491693/docs/834nd-2241/834nd-3721)). The next step is to collect the initial requirements using Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-12080](https://app.clickup.com/8491693/docs/834nd-2241/834nd-12080)) and define the primary business need, measurable project goals, constraints, and assumptions. Agreements with 3rd parties must be reviewed as well. Further, BA's work relates to thePrivate (https://app.clickup.com/8491693/docs/834nd-2241/834nd-7062).
1. Depending on the requirements, governance, and Client demands, AM and PM have to pick the suitable cooperation model amongPrivate ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-4281](https://app.clickup.com/8491693/docs/834nd-2241/834nd-4281)), which impact all other processes starting at the project planning phase. There are three of them DevCom currently works with:
1. **Fixed price contract**
2. **Time & material**
3. **Monthly budget contract**
3. With Tech Lead, AM defines the technology stack with further CTO approval.
4. AM or Project Administrator starts a project in DCM with available information. One shall hold the internalPrivate (https://app.clickup.com/8491693/docs/834nd-2241/834nd-9568) to inform the people involved.
5. AM with a PM and Tech Lead plans the preliminary team composition based on the known scope and balances people's levels of expertise so that the project is profitable and there is enough room for self-development.
6. PM defines how to track project progress using various metrics.
7. AM, PM, BA, and Tech Lead conduct an overall initial risk analysis related to the primary business need.
8. PM gathers and prepares the information about how the project will look like: approach, methodology, roles, and uses the Private (https://app.clickup.com/8491693/docs/834nd-2241/834nd-6428) to choose the right tools.
* Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-7082](https://app.clickup.com/8491693/docs/834nd-2241/834nd-7082))
* Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-3721](https://app.clickup.com/8491693/docs/834nd-2241/834nd-3721))
* Choose necessary Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-3821](https://app.clickup.com/8491693/docs/834nd-2241/834nd-3821))
* Task management
* There may be other tools the team needs access to before the start. Think of tech design, databases, and UI artifacts like fonts, style guides, and logins.
The steps above may be part of the Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-4441](https://app.clickup.com/8491693/docs/834nd-2241/834nd-4441)).
AM or PM holds the Private (https://app.clickup.com/8491693/docs/834nd-2241/834nd-7502) meeting to wrap up the abovementioned information.
# Step 2. Proposal
The goal of every project is to get financial, social, or other types of benefits. Thus all stakeholders strive to spend the minimum time, effort, and resources to get the working product or service. We call it the **minimum viable product** (MVP).
After the scope of MVP was planned, AM and PM had to control the scope and budget precisely. Regardless of the cooperation model, he acts accordingly:
* Monitors the scope completion progress
* Monitors the budget usage.
After the initial requirements are understood, the Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-4041](https://app.clickup.com/8491693/docs/834nd-2241/834nd-4041)) is crafted. When more information is available/known, AM uses the [Proposal template](https://docs.google.com/document/d/1ywuXn0GMNWjGAuI1DqQcGROOJKFQGKvYiCak3XxP994/edit?usp=sharing), which must contain links to other documents, including specifications of requirements on different levels of abstraction: business requirements and rules in Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-7102](https://app.clickup.com/8491693/docs/834nd-2241/834nd-7102)), user requirements, and solution requirements in the form of Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-7662](https://app.clickup.com/8491693/docs/834nd-2241/834nd-7662)),Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-11800](https://app.clickup.com/8491693/docs/834nd-2241/834nd-11800)) or Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-7682](https://app.clickup.com/8491693/docs/834nd-2241/834nd-7682)).
The rest of the scope will become a part of upcoming product releases.
One must avoid the situation when 80% of the budget produced less than 50% of the planned outcome. It is recommended to chunk the scope and budget into 4 even pieces and monitor the execution to shift one or more variables in the project management triangle.
# Step 3. Project Initiation
1. Before starting any further work, the team must be familiar with Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-11040](https://app.clickup.com/8491693/docs/834nd-2241/834nd-11040)) when working with sensitive user data. This may include:
1. Linking accounts to work email only
2. Logging and storing activities performed within environments
3. Setting up the monitoring of the security status of development by automated tools.
2. When the first iteration or phase is about to be planned, follow the Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-4001](https://app.clickup.com/8491693/docs/834nd-2241/834nd-4001))to utilize the best practices for better work planning.
3. The daily check-ups are effective and are part of planned events recorded in Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-7082](https://app.clickup.com/8491693/docs/834nd-2241/834nd-7082)).
4. Sprint Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-3881](https://app.clickup.com/8491693/docs/834nd-2241/834nd-3881)) helps to prepare items for the next planning meeting. Even in an agile environment, it helps to plan in advance and see the dependencies that are usually revealed during the Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-11920](https://app.clickup.com/8491693/docs/834nd-2241/834nd-11920)).
5. For these events, PM uses the recommended [](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-6428?block=block-6cb61d3a-f95a-4d9c-81ac-026103c75a3d).
6. Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-7022](https://app.clickup.com/8491693/docs/834nd-2241/834nd-7022))is conducted regularly, and the information is well-communicated to the stakeholders.
7. Within the Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-7082](https://app.clickup.com/8491693/docs/834nd-2241/834nd-7082))PM plans each Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-3921](https://app.clickup.com/8491693/docs/834nd-2241/834nd-3921)), like Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-7382](https://app.clickup.com/8491693/docs/834nd-2241/834nd-7382)). A complete and comprehensive Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-3901](https://app.clickup.com/8491693/docs/834nd-2241/834nd-3901))process is essential for all team members as the team goes through the Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-9241](https://app.clickup.com/8491693/docs/834nd-2241/834nd-9241))and evolve with time.
8. To have a better understanding of who is doing what within DevCom's team, PM can use the Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-7522](https://app.clickup.com/8491693/docs/834nd-2241/834nd-7522)).
# Step 4. Requirements
1. When working with Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-7062](https://app.clickup.com/8491693/docs/834nd-2241/834nd-7062)), the team already knows the format and can choose one of the Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-4121](https://app.clickup.com/8491693/docs/834nd-2241/834nd-4121)).
2. The initial requirements are part of the Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-7102](https://app.clickup.com/8491693/docs/834nd-2241/834nd-7102)). For better Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-7702](https://app.clickup.com/8491693/docs/834nd-2241/834nd-7702))use DevCom's template. It is ok to embrace changes on a project; however, monitoring them is even more significant due to constraints like time or budget. Make sure to monitor the Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-4241](https://app.clickup.com/8491693/docs/834nd-2241/834nd-4241)).
3. To continue the work with upcoming milestones, PM and BA are considering using the Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-3981](https://app.clickup.com/8491693/docs/834nd-2241/834nd-3981)).
4. PO with the team prioritizes and allocates requirements for the upcoming releases to the project phases and sprints. It's recommended to use Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-3881](https://app.clickup.com/8491693/docs/834nd-2241/834nd-3881)) and PM works primarily on it.
# Step 5. Design
1. Technical design is a predecessor of actual development and should be done accordingly. PM must verify with Tech Lead that the information in [Project Software Architecture](https://docs.google.com/document/d/1vjs_aurK5REik5Ir2Vb_eE7xnnNHKsXDH7CIcdyOYGA/edit?usp=sharing) is up to date and followed by the development team.
2. The UI/UX design goes through the iterative process and final approval by a Client.
# Step 6. Development
1. The technical project blueprint defines the environmental and infrastructure needs, code convention, source control strategy ([branching & merging](https://docs.google.com/document/d/1grNCNBHTaR-5wYZU39e_Pql3aC2iO-k9GTfn8bup6sg/edit?usp=sharing)), the code review process, unit testing strategy, Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-4241](https://app.clickup.com/8491693/docs/834nd-2241/834nd-4241)) in Production, etc.
2. For faster development, PM utilizes continuous integration, deployment practices, and Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-4181](https://app.clickup.com/8491693/docs/834nd-2241/834nd-4181)) in case of emergency.
3. Last but not least, practice here is the technical debt management process. PM must avoid Sprints filled with refactoring tasks only. Technical debt should be taken in small amounts each Sprint whenever possible so that a snowball effect won't occur.
4. The project's progress can be assessed in multiple ways. Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-4361](https://app.clickup.com/8491693/docs/834nd-2241/834nd-4361))has a set of metrics to do that and covers versatile areas:
1. Velocity and deviation
2. Stories and tasks data
3. QA statistics
4. HR statistics
5. Development metrics
# Step 7. Testing
1. Sometimes one of the challenges is to define the test plan and strategy, including applicable techniques, like Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-4301](https://app.clickup.com/8491693/docs/834nd-2241/834nd-4301)), test cases, and reports. It requires collaboration with QA representatives and utilizing Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-4201](https://app.clickup.com/8491693/docs/834nd-2241/834nd-4201)). The sooner they get implemented, the better level of quality is achieved.
2. And to prepare those artifacts properly, a team works together on two prime definitions:
1. thePrivate ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-7602](https://app.clickup.com/8491693/docs/834nd-2241/834nd-7602)) to eliminate any ambiguity, dependencies and
2. the Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-5341](https://app.clickup.com/8491693/docs/834nd-2241/834nd-5341))to ensure the team delivers the value according to the [](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7662?block=block-5fc6b20d-495f-44f0-8e9c-521a10b580d0).
3. When the major defects and malfunctions are tracked in the Production environment, PM ensures that the proper Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-7202](https://app.clickup.com/8491693/docs/834nd-2241/834nd-7202)) is being held to avoid the reoccurrence.
4. Also, the Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-7042](https://app.clickup.com/8491693/docs/834nd-2241/834nd-7042))ensures the requirements management flow is set and followed, and communication with the client and the team is performed regularly and with the appropriate level of detail. Usually, BA is in charge of this audit.
# Step 8. Delivery
1. The release process and its plan can be found in the Roadmap, Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-3881](https://app.clickup.com/8491693/docs/834nd-2241/834nd-3881)), other documents or tools (e.g., Jira).
2. After the phase, sprint, or significant amount of work is accomplished, formal sign-off of deliverables is conducted through Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-7322](https://app.clickup.com/8491693/docs/834nd-2241/834nd-7322)) and PM presents it.
3. Sprint demo is held on the last day of Sprint by default as part of the interim review or Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-4381](https://app.clickup.com/8491693/docs/834nd-2241/834nd-4381)). It represents the visual part of deliverables done during the project phase or Sprint.
4. The (Sprint) Retrospective concludes the iteration or phase, and its purpose is to plan ways to increase quality and effectiveness. The Team inspects how the last iteration went with regard to individuals, interactions, processes, tools, and their Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-5341](https://app.clickup.com/8491693/docs/834nd-2241/834nd-5341)). The informal agreements among the stakeholders, as well as the links to other artifacts, should be recorded in the Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-3841](https://app.clickup.com/8491693/docs/834nd-2241/834nd-3841)).
# Step 9. Support
1. Project support can be part of an existing contract or a separate **Support Agreement**.
2. AM, PM, and Client representatives shall consider the Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-4161](https://app.clickup.com/8491693/docs/834nd-2241/834nd-4161))after the initial major release scope was delivered. It can be part of the **Support Agreement** or a separate artifact.
3. End-user education must be thoroughly planned usingPrivate ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-3961](https://app.clickup.com/8491693/docs/834nd-2241/834nd-3961)) practice and PM (or assigned team member) educates them on how to use the system.
4. The improvement plan is usually created as part of retrospectives from a list of items after each iteration or process implementation.
5. The Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-5781](https://app.clickup.com/8491693/docs/834nd-2241/834nd-5781)) suits these needs and can quantify the progress. For better results monitoring, PM measures the data at the start of a phase or a Sprint and then again after a few iterations or a specific time frame.
# Project Maturity Scale
# General Information
The Project Management Maturity Model (PMMM) is a concept that helps project-based organizations assess their projects in terms of management and growth. The more activities and processes are well set according to the company's standards, the better outcomes projects can provide.
PMI [studies have shown](https://www.pmi.org/learning/library/pm-maturity-industry-wide-assessment-9000) that businesses with poor Project Management performance are more likely to face financial loss due to increased costs per project. Another downside is low-quality outputs, not only because each project goes differently but because there are no minimum standards.
The original PMMM started as a framework developed by the Software Engineering Institute (SEI) at Carnegie Mellon University in the mid-1980s. The primary purpose was to help the government evaluate software contractors for a further decision to choose the best to deliver complex projects. The framework had a set of metrics to analyze the standard practices maintained by a company while working on software projects.
Since then, the framework has been adjusted to fit a broader range of industries, which is why several models are present today. Among them:
* Center for business practices
* Organizational Project Management Maturity Model
* Kerzner's PMM model
* Capability Maturity Model
* ESI international's project framework
* Berkeley Project Management Process Maturity Model
* SEI's capability maturity model integration
Looking at all of these and having more than 20 years of experience delivering value through software project execution, we decided to take the best practices and create our standard - **Project Maturity Scale (PMS)**.
# 
# Five levels of PMS
Here are some characteristics of project management maturity:
* Projects are completed within a given timeframe
* Teams mitigate risks and work on improvements
* Finished projects match with original goals
* Projects create value
* Projects continue successfully despite changes
It is easy to evaluate something on a scale from 1 to 10, but it's even simpler from 1 to 5.
## First Level. Ad Hoc
This is the initial project management attempt where practices are chaotic, and there is little to no consistency between projects or the use of project management tools. The project's success is very dependent on the initiative and capability of team members. The company most likely lacks consistent teamwork. There is an undocumented management process.
**Advancing from Ad Hoc to Varied:** A company recognizes the patterns to start project management. Teams need to be trained to understand the basics of methodologies of project management, techniques, and why they are different.
## Second Level. Varied
A company strives to implement standards as some events are repeatable and processes look alike. Project managers track costs, timings, and scope. Teams plan project activities and create first reports to provide high-level overviews of the progress.
Usually, the big projects consistently adhere to these standardized processes, while smaller projects fly under the radar. This means there is no common approach regarding project management, which is likely to depend on key individuals in the company.
* Partially repeated and documented processes
* Basic
* Stakeholder Management
* Requirements Management
* Project Planning and Review
* Configuration Management
* Subcontract Management
**Advancing from Varied to Synergy:** Teams understand and utilize the underlying principles of project management. A company introduces processes and emphasizes scope, time, and cost monitoring.
## Third Level. Synergy
When a company documents processes and integrates them into all projects throughout the organization, it points to creating the documentation that helps define the relationship between management and teams, the company, and clients.
Teams are aware of processes and can reliably implement them. Most projects are completed on time and have low to zero deviation of costs.
A company incorporates regular employee training, workshops, and peer reviews and promotes standards.
* Repeated and documented processes
* Advanced
* Stakeholder Management
* Requirements Management
* Change Management
* Risk Management
* Quality Management
* HR Management
* Organization Process Focus
* Peer Reviews
* Training Programs
* Software Product Engineering
* Integrated Software Management
**Advancing from Synergy to Standards:** Companies focus on quality management, concurrent engineering practices, and various management techniques. They refine processes and choose the best approach.
## Fourth Level. Standards
A company implements a clear set of metrics to track the project's success and assess the current level of productivity. Processes are homogeneous, and one can qualitatively evaluate them. Team members and management have a good sense of project status, defined reports, requirements flow, and value delivery practices.
* Company/industry-defined KPIs
* PMO and Standardization
* Portfolio Management
* Executive Oversight
* Quantitative Process Management
**Advancing from Standards to Optimization:** Companies track different metrics and adopt internal and external benchmarks. They emphasize consistently choosing and tailoring knowing practices and applying them to projects to support strategic objectives.
## Fifth Level. Optimization
A company adjusts previously established processes based on empiricism, lessons learned, and innovative practices. While it pursues continuous improvement efforts, some approaches to improvement include efforts to reduce and prevent defects and incorporate automation where applicable.
* Project Maturity Assessment
* Project Management Skills Assessment
* Project Management Certifications
* Technology Change Management
* Defect Prevention Process
**Maintaining Optimization:** Companies pursue continuous improvement and select projects that match strategic plans. They create their own standards, innovate, automate, and educate their peers (Clients and employees).
# Areas
### Goals and Objectives
* Project objectives in the form of a Roadmap, milestones list, or similar have been communicated to the project team and can be measured
* Project KPIs (planned/delivered scope metrics, tasks execution metrics, QA metrics, HR metrics, development metrics) and their baselines have been agreed upon with the Account Manager
* Project information (goals, constraints, challenges, etc.) is always communicated to the team
* There is an alignment between legal documentation (e.g., SOW), selected project model, and project objectives
* Impact on all project plans and project-related documentation is always assessed in the case at least one of the project objectives has been changed
### Stakeholders
* All project stakeholders are identified
* Stakeholders' needs have been analyzed with the Power Interest grid (or other)
* Stakeholders are appropriately engaged according to interest and impact
* A vacation plan has been created and kept up-to-date
* Project team agreements and rules (code of conduct) have been collected, systemized, and documented in the Agile/Team Charter
* Roles and responsibilities have been clearly defined and documented within the project using the RACI matrix or similar
* Necessary team-level knowledge sharing has been identified and planned
* The current project team composition is effective and aligned with the workload
* Team building activities are performed regularly
* Action items for team performance improvements are defined during regular discussions ( retrospectives, interim (sprint, iteration, phase) reviews) and implemented according to priorities
* Comprehensive and complete feedback is provided to all team members (one-to-one meetings)
* The new team member ramp-up procedure is easy and fast to perform
### Communication
* Communication tools have been defined within the project (web/phone conference, project documentation space)
* Regular project-related meetings have been defined and scheduled
* Escalation rules have been defined within the project
* Regular meetings are performed according to the planned schedule
* The communication artifacts (meeting notes, status reports, list of action items) are presented in a consistent format according to the predefined template
* Client needs/expectations are validated regularly
* The project has kick-off meetings for each phase (or similar for iterations)
* The team adheres to company policies and documentation
### Requirements
* Requirements Management processes are set up, agreed with project stakeholders, documented, and followed
* There are no delays with requirements communication to the engineering team
* Business analysis for elicitation sessions is conducted according to the plan (goals, elicitation techniques, agenda is prepared and communicated to the stakeholders before the event)
* Requirements are described with enough detail for the implementation team to create a technical design
* Requirements are verified for quality (definition of ready)
* Non-functional requirements are specified and documented
* The workflows, data flows, use cases are analyzed and modeled (process modeling, use cases and scenarios, data flow diagram, context diagram, state machine diagram, sequence diagram)
* Requirement dependencies and constraints are identified
* Ready-for-development requirements are provided to the team on time
* The development team gets a minimum amount of minor change requests in each iteration
* Completed work is constantly validated and accepted by the responsible person (e.g., product owner, Client)
* All requirements are clear and have the defined acceptance criteria before estimation
* The development team participates in the estimation process
* The scope is divided enough for accurate estimation
* Risks are included in the estimate
* Experts with corresponding experience are involved in estimation in case of need
### Scope
* Activities (or user stories to be implemented during the current iteration) are always defined and logged in the task-tracking tool
* Efforts required for each activity implementation are estimated
* The impact of a change request is always assessed in terms of the time required for change implementation
* Scope change identification and tracking process have been established
* The team knows about future releases
* There is a documented high-level architecture of the project
* The technical debt items are constantly being identified, documented, and processed
* Pay down of technical debt is conducted on a regular base
* There is an actual Disaster recovery plan
* Work items are located in a single backlog
### Code
* Code analysis tools are in place and run each time
* Code review process was established and automated
* Code conventions (patterns, rules, style) are defined, approved, and followed
* Automated build systems and continuous integration are setup and configured
* The source control and branching strategy is documented and shared with everyone
* The environmental and infrastructure needs are defined
### Testing
* Test Strategy/Test Plan is reviewed regularly
* The functionality to be tested is defined and documented
* Appropriate tools are defined
* QC Engineers participate in requirements analysis and refinement processes
* Test cases/checklists and test suites are designed according to the company's approved standards
* A separate environment for User Accepting Testing (e.g., Sandbox) is used for testing purposes
* Smoke testing is performed
* Functional testing is performed
* Regression testing is performed
* End-to-end (simulating main flows used by end users) testing is performed
* Non-functional testing is performed in case it is required
* Usability testing is performed in case it is required
* Reliability testing is performed in case it is required
* Performance efficiency testing is performed in case it is required
* Maintainability testing is performed in case it is required
* Security testing is performed in case it is required
* Compatibility testing is performed in case it is required
* Root cause analysis procedure is established for high-severity defects and defects reported by clients
* Test Automation scope is defined/reviewed regularly
* Unit testing is part of the development cycle in applicable iteration
* Test logs are collected and analyzed regularly
* CI environment for running automated tests is established
### Security
* All team members had passed security training
* Security requirements are developed for the project
* The team receives the minimum required permissions for work
* All accounts are linked to work email
* All actions on environments are logged and stored
* Security and penetration tests are specified based on requirements and executed
* Project-related scripts (configuration, build, deployment, database upgrade) are stored in the source control
* Binaries (output of compilation) and user settings are not stored in the source control
* The development team stores code changes in source control regularly (at least once in 1-2 days)
* Code review tasks are of a higher priority than a development one
* CI build configuration contains the following basic steps: automatic building, automatic unit/integration test running, artifacts creation, and storing
* Code is built locally before committing to the pipeline
* Every developer commit (push) goes through the pipeline
* Code from all needed branches is built on CI
* Build artifacts are versioned
* The deployment to different environments (test, stage, production, etc.) is automated
### Risks
* The risk management process has been communicated to stakeholders
* Identified risks are documented in the project risk register according to probabilities and impact
* Qualitative and quantitative risk analysis has been performed for identified risks
* A mitigation and contingency plan is developed and documented for identified risks
### Delivery
* The release process and plan are defined and approved
* The work acceptance procedure for deliverables (review, sign-off of the iteration/phase completion) is defined and documented
* Regular Client feedback is received during interim and final demonstrations
### Budget
* All the costs related to project scope implementation have been estimated
* The project budget has been calculated based on costs (salaries, contingency/management reserve, user acceptance testing, maintenance/support)
* Financial forecasts are up to date
* There is a plan for how to maintain profitability at the minimum level
* The budget is aligned with promotions and rewards and communicated to the Client
* The impact of a particular change request is always assessed in terms of related costs
### Scrum
* Project Scope Baseline has been clearly defined at the iteration level
* Project Scope Baseline has been clearly defined at the release level
* Project Scope Baselines at all levels (iteration/release) have been agreed upon with the Client
* Project requirements are clearly defined at the required granularity (definition of ready) for at least one upcoming iteration
* Acceptance criteria for all planned activities (tasks) have been clearly defined
* Implemented requirements are verified against defined acceptance criteria and formally accepted by the Client during the interim reviews (sprint reviews, demos)
* The scope of work to be delivered within the iteration is defined/planned before the start of an iteration
* The scope of work to be implemented within the iteration is estimated before the start
* Task tracking tool (Jira, Asana, ClickUp, Redmine, etc.) is used to support the requirements management process
# Evaluation Scale
* **5 - Outstanding** - the key practices are _implemented to a degree not commonly found or optimized to the level of proprietary practice._ _Activities are performed regularly, and most of them are automated._ Synonyms are best-of-breed, superior, exemplary, and world-class. Applicable for Optimization Level.
* **4 - Plentiful** - the key practices are _complete, appropriately planned, and consistent among similar projects._ _Activities are performed regularly according to industry and/or company standards._ Synonyms are compliant, done, complete, and benchmark. Applicable for Benchmark Level.
* **3 - Sufficient** - the key practices are _thoroughly planned, appropriately documented, and consistently practiced._ _Activities are performed regularly._ Synonyms are good, prepared, ready, in practice, and implemented. Applicable for Synergy Level.
* **2 - Acceptable** - the key practices are _sporadically performed, or there is little process documentation or few artifacts. Activities are performed once and randomly._ Synonyms are sometimes informal, unwritten, partial, in progress, or scheduled. Applicable for Commonality Level.
* **1 - Poor** \- the key practices have _never been or are not being meaningfully planned or performed._ Synonyms are none, nonexistent, mediocre, inappropriate, inadequate, impractical, ineffective, irrelevant, and worthless. _Activities are not performed or performed randomly._ Applicable for Ad Hoc Level.
* **N/A** - not applicable to a project.
# How to Use the Scale
A project must have some processes and artifacts in place at every maturity stage. With time these processes should scale, adapt, and improve. One must use the evaluation system using the guide above to track that progress.
The evaluation tool calculates the following metrics:
* **TOTAL** \- the total points earned during the assessment
* **Average** \- the average score of **TOTAL** points
* **Relative Performance (what we head toward)** \- shows the closest Level of maturity where improvements are still needed. For instance, if it shows 95%, it also highlights the same number for the Level where we want to be soon. After we reach 100%, it will show less than 100% for the next one, telling how much we need to advance.
## Instructions
* Copy the spreadsheet
* Assess a project or Unit on a scale from 1 to 5
* Check the overall score (**ALL** sheet) and/or particular sections for better in-depth analysis
* See the OVERALL (AVERAGE) PMS SCORE (**OPS**) for the average score of each section.
# Template
[https://docs.google.com/spreadsheets/d/1Z6lLgW6wkIc0Fb3R8BB\_oYeYwricX3irJ5sJseI1xmc/edit?usp=sharing](https://docs.google.com/spreadsheets/d/1Z6lLgW6wkIc0Fb3R8BB_oYeYwricX3irJ5sJseI1xmc/edit?usp=sharing)
# Project Support Flow (SLA)
Every project support requires resources to maintain its flexibility to generate even more value. Any Help Desk system helps to manage user requests and react to various inquiries from other stakeholders. To simplify the flow of this process, one has to create a set of rules and terms.
After the project closure, parties may agree to any obligations to be kept as part of the after-sale agreement.
TEXT in **_bold_** **_italic orange (_****_including links in_** **_light blue_****_)_** is meant to be adopted by each project.
# Guideline
Tasks that come through the Support channels must be categorized, so that they are filtered and defined as true support activity, research, or even feature requests. These categories represent different activities and are used to group inquiries and naturally generate '**feature requests**'. They might be as follows: User data change, User Management, Subscription Update, Feature request, Other, etc.
Thus we can apply the scenario below for support activities only as other types are applicable to regular [**_task flow_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3981?block=block-0fef77a7-b975-4e54-96de-6546ad729acc).
## Scenario
1. A **Requester** submits a ticket with the urgency status
2. The **Support Manager** reviews the ticket and
1. Assigns Priority **Urgent****,** **High****,** **Normal****, or** **Low**
2. Status **OPEN**
3. Sub-status **NEW**
4. Category (_unique per project_)
5. The Assigned role should be **DevCom's** representative.
3. **DevCom Support Manager** receives the notification email at **_10:00 AM_** UA time and
1. Set Priority (e.g. if **Urgent** it must be reviewed by **_12:00 PM)_**
1. If there are no questions:
1. Set the Status **OPEN** and Sub-status **ACCEPTED**
2. If there are questions or missing information:
1. Then reply with a question and set Status **PENDING**
2. Create a ticket in the task tracking system and assign it to the **Developer**
1. _Priority_ **_Urgent_**_, then review by_ **_12:00 PM_**
2. _Priority_ **_High_**_, then review by_ **_2:00 PM_**
3. _Priority_ **_Normal_**_, then review by_ **_4:00 PM_**
4. _Priority_ **_Low_**_, then review due date_
5. Set Sub-status **WORK ASSIGNED**
4. **Developer**
1. Receives notification
2. And based on Priority
1. Sets Sub-status **WORK QUEUED** or **WORK IN PROGRESS**
3. When the work is Completed
1. He sets Sub-status **WORK COMPLETED**
4. After the outcome is tested/validated
5. He sets the Status **PENDING** and adds a comment with the resolution, reassigns a ticket to **Requester,** and asks to verify the change
5. A **Requester**
1. Receives notification
2. Verifies the changes and sets the status to **SOLVED**
## Notes
* Sub-statuses (only applicable to Status **OPEN** or **PENDING**)
* **NEW** - initial status of a request
* **ACCEPTED** - indicates that someone at **DevCom**, most likely the **Support Manager** reviewed the content of the ticket, and it is either known issues or tasks, and there is no missing data or information
* **WORK ASSIGNED** - the ticket is assigned to a **Developer**
* **WORK QUEUED** - a **Developer** reviewed the ticket, understands what is asked, and agrees to complete the work within **SLA** or by the due date
* **WORK IN PROGRESS** \- work is started
* **WORK COMPLETED** - development is completed
* **WORK ON HOLD** - work is on pause for some reason; one must post a comment with reason unless understood from existing comments
* **WORK CANCELED** - work is canceled for some reason; one must post a comment with a reason unless understood from existing comments
# Service Level Agreement (SLA)
SLA is designed to set guidelines and principles for parties involved in production support. It is for internal use only but can be shared with business partners if needed. Prior to sharing the SLA externally, it must be approved by key stakeholders from both DevCom's and the Client's sides.
It is recommended to use a 3rd party software, allocate a dedicated resource to work under SLA, and cover the responsibilities. However, if a 3rd party software is subject to extra expenses, it can be substituted by other means (chat applications, cloud drives, file-sharing solutions, office documents, etc.). The core development team and management team can share the responsibilities if the dedicated resource is unavailable. Work on production support under SLA should meet the below requirements:
* * **_< 2 hours_** - business the time from the reception of the notification by a person;
* {due date} - **Low** or **Normal** tickets may have a due date
* **Urgent** or **High** tickets typically must be done within pre-defined SLA
* **Urgent**
* Less than **_2_** hours to acknowledge (**ACCEPTED**)
* Less than **_2_** hours from reception by a developer (total less than **_4_** hours from reception by **DevCom**) to set **WORK IN PROGRESS**
* The completion is expected the **_same day_** or no later than the **_next day_**; if this is not feasible one must notify through the means of communication (messengers, task/ticket tracking system)
* * **High**
* Less than **_4_** hours to acknowledge (**ACCEPTED**)
* The completion is expected within **_3_** business days; if this is not feasible, one must notify through the means of communication (messengers, task/ticket tracking system)
* * **Normal**
* Less than **_6_** hours to acknowledge (**ACCEPTED**)
* The completion is expected within **_10_** business days; if this is not feasible, one must notify through the means of communication (messengers, task/ticket tracking system)
* For **Normal****,** we will also use due dates
* * **Low**
* Less than **_8_** hours to acknowledge (**ACCEPTED**)
* We will also use due dates for **Low**s
* * Additional communication requirements
* If a ticket was submitted after DevCom work hours, the **ACCEPTANCE** must be done by **_7:00 AM EST_** the **_next day_**
* If a ticket was submitted between **_3:00 PM_** and **_5:00 PM_** local DevCom time, the ticket must be **ACCEPTED** **by the end of** DevCom work hours
* If a ticket was submitted after **_5:00 PM_** local DevCom time, it would be good but optional that a ticket is **ACCEPTED** _by the end of_ DevCom work hours. It must be **ACCEPTED** by **_7:00 AM EST the next business day_**.
The communication flow in any system should be quite simple:
Tier 3 (**DevCom**) answers Tier 2 (**Client** **representatives**), Tier 2 answers Tier 1 (**customers**)
A sample diagram of the support process can be found below. It anticipates there is a Help Desk system to work with users' inquiries. It also means that roles are assigned, and all parties accepted the terms of the support process.
Additionally, the support person working on a request, who sees a possibility to enhance the process or system flow, should notify the responding PM about this. PM will coordinate next if the suggestions can be implemented.
[]()
# QA Strategy & Practices
[Ukrainian version of this guideline](https://docs.google.com/document/d/1k9aBRRD6socBsDdiHLdW5VY4oF59z07BaXMcYABOsEY/edit?usp=share_link)
Once the task has gone through code review, QA flow, and has defects in later stages or environments, one must record that as a **bug**.
TEXT in **_bold_** **_italic orange (_****_including links in_** **_light blue_****_)_** is meant to be adopted by each project.
# **Rules For Developers**
1. Code the best you can
2. Review and run your code
3. Ask for a code review by your Tech Lead or Senior Developer
4. Provide the QA representative with the evidence (_comment, screenshot_) you did your check, and he/she may test further
5. Test the task while it moves between Environments until it's **DONE**.
The agile framework encompasses expertise within the team to deliver features and ensure they are **DONE**.
# **First Steps**
* Develop Quality Plan; it must include various testing techniques and described processes with templates.
* Requirements are clear for all team members regardless of their role and position.
* Acceptance criteria must quantify the understanding of success and present deliverables, not actions.
* [**_Definition of Done_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3941) is applicable after the task is delivered to the final Environment (Production)
* Provide visual proof of task checking (_comment, screenshot_)
* Set up [**_communication_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3921) with people who can answer questions and help solve the issue based on [**_Stakeholder Management inputs_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3721).
# **Short-Term Recommendations**
* When a task changes its status to another, one must add a comment. This is the formal confirmation that it was checked by the person who changed that status.
* Fewer tasks are left to test at the end of a Sprint (_testing must be conducted without or with minimum delay_). This also implies chunking tasks into smaller pieces during the Sprint planning.
* Low-priority tasks (_such as investigations, documentation, and design_) must be executed in the last two days unless urgent or block other activities.
* The 'bug category' is present in the task tracking system to analyze the root cause of the bug (**_poor acceptance criteria, poor description/explanation, not enough time to test (_**_applies_ _to a single task or regression_**_), business logic complexity, post adjustments, bad code, 3rd party defects, poor tech design, poor code review_****).**
* Link tasks with bugs in the task tracking system.
* Knowledge sharing
* rotates QA representatives among teams once in a while;
* maintaining up-to-date QA documentation (checklist for "happy path", test cases, smoke tests, regression testing).
* It is nice to have stakeholders representing users (_could be Product Owner_) to verify important tasks as "**_ready for Production_**" before updating the final Environment. Treating them as beta-users will help catch the typical 'user-bug' before it occurs in Production.
# **Long-Term Recommendations**
* Unit testing is part of the regular development process
* 'Code freeze' (_or similar practices_) to prevent new changes to certain Environments to allow QAs to do the regression testing
* When the project goes live, one must periodically review and analyze the support requests. The outcome is a new feature development or improvement to reduce support inquiries
* Automate the testing process using various tools and frameworks.
# Responsibilities (PM, PC, PA, AM)
# Project Manager & Coordinator
The **Project Manager** is the person assigned by the performing organization to lead the team responsible for achieving the project objectives. PM provides the project team with leadership, planning, and coordination through communications.
A **Project Coordinator** is a professional who helps a company with administrative tasks for specific projects and ensures that everything runs smoothly so the project manager can achieve the company's goals.
The Project Manager (PM) and Project Coordinator (PC) are successful when the project objectives have been achieved. Another aspect of success is stakeholder satisfaction, including needs, concerns, and expectations. To be successful, PM/PC should tailor the project approach, life cycle, and project management processes to meet the project and product requirements.
Good **Project Managers** might have more than one project coordinator to take care of all the tasks involved with scheduling, budgeting, and task creation. Due to the seniority of the role and the more responsibilities it entails, the **Project Manager** should have strong leadership skills.
**Project Coordinators** complete duties like these to give project managers the time to handle bigger issues.
# Sharing Responsibilities PM, PC, PA, AM
[https://docs.google.com/spreadsheets/d/1eVQwdK7FlThJteT6ti5ghz2RNTfKXutHtx9stbM7YHc/edit#gid=0](https://docs.google.com/spreadsheets/d/1eVQwdK7FlThJteT6ti5ghz2RNTfKXutHtx9stbM7YHc/edit#gid=0)
# Delegating Responsibility
1. **Awareness:** the purpose of the task, measurable effect, and the impact of not holding it.
2. **Standard of Performance:** specific, measurable deliverables such as deadline, delivery form, reporting, compensation, etc.
3. **Power to Act**: capability: knowledge, skills, resources, authority/capacity: time and attention
4. **Commitment:** clear, explicit commitment to hold this responsibility.
# Risk Management
[Ukrainian version of this guideline](https://docs.google.com/document/d/1qPtFUilus1oiDurMk6lOIwEcEZKcHrlyQThraBDWjSk/edit?usp=share_link)
Uncertainty presents threats and opportunities that project teams explore, assess, and decide how to handle.
Find the [**Template**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-25140) [](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-25140)[**here**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-25140)
A risk event is an unidentified event that may or may not happen. It can have positive (opportunities) or negative (threats) impacts on the project if it does happen.
The risk management process is very iterative!
Uncertainty can be presented in various forms:
* Risk is associated with not knowing future events.
* Ambiguity is associated with not being aware of current or future conditions.
* Complexity is associated with dynamic systems having unpredictable outcomes.
* Volatility is associated with unstable conditions and/or a state of events.
# Risk Responses
When looking at risk, it’s necessary to determine the following:
* The probability that a risk event will occur (how likely);
* The range of possible outcomes (impact or amount at stake);
* Expected timing for it to occur in the project life cycle (when);
* The anticipated frequency of risk events from the source (how often).
All stakeholders should participate in identifying risks from their perspective.
# 
The plan to cope with risks may include doing one or a combination of the following:
* Actions to eliminate the threats before they happen;
* Actions to make sure the opportunities happen;
* Decrease/increase the probability and/or impact of threats;
For the remaining (residual) threats that cannot be eliminated:
* Reduce the risks happening chance and increase the probability of opportunities (mitigation plans).
* Contingency plans should be measurable so you can evaluate their effectiveness.
* Actions if contingency plans are not effective or are partially effective (fallback plans).
The choices of response strategies for **_threats_** are:
* **Avoid**. Eliminate the threat by eliminating the cause, such as removing the part of work or a person. Avoiding the threat might even involve expanding the scope of the project.
* **Mitigate**. Reduce the probability and/or the impact of a threat, thereby making it a smaller risk and possibly removing it from the list of top risks on the project. Any reduction will make a difference, but the option with the most probability and/or impact reduction is often the option selected.
* **Escalate**. Escalation is appropriate when the project team or the project sponsor agrees that a threat is outside the project's scope or that the proposed response would exceed the project manager’s authority.
* **Transfer (deflect, allocate)**. One can make another party responsible for the risk by purchasing insurance, performance bonds, warranties, or guarantees or outsourcing the work. The strong connection between risk and procurement (contracts) begins here.
The choices of response strategies for **_opportunities_** are:
* **Exploit**. Add work or change the project to make sure the opportunity occurs.
* **Enhance**. Increase the risk event's likelihood (probability) and/or positive impacts.
* **Escalate**. This opportunity response strategy is used when the project team or the project sponsor agrees that an opportunity is outside the project's scope or that the proposed response would exceed the project manager’s authority.
* **Share**. Allocate ownership or partial ownership of the opportunity to a third party (forming a partnership, team, or joint venture) that is best able to achieve the opportunity.
A common strategy for both _threats_ and _opportunities_ is to **Accept** them. Active acceptance may involve the creation of contingency plans to be implemented if the risk occurs and the allocation of time and cost reserves to the project. If a risk occurs, passive acceptance leaves actions to be determined as needed (workarounds).
## Contingency reserves
They are known during risk identification and planning; management _reserves_ aren’t identified in risk management (“unknowns”). Contingency reserves are calculated and become a part of the cost baseline. Management reserves are estimated (e.g., 5% of the project cost), and then these reserves need a management’s approval to be used as they are extra costs, but not additional costs.
Avoidance and mitigation would generally be used for high-priority, high-impact tasks. Transfer and acceptance are appropriate for low-priority, low-impact risks.
Risk mitigation planning develops options and actions to enhance opportunities and reduce threats to project objectives. Risk mitigation implementation is the process of executing risk mitigation actions. Risk mitigation progress monitoring includes:
* tracking identified risks,
* identifying new risks,
* and evaluating risk process effectiveness throughout the project.
When all actions to soften the impact are executed, the contingency plan comes. But the best strategy is to be proactive rather than reactive. Try to prevent the risk from happening and evaluate the efforts (resources to be allocated to soften the impact) before any action occurs.
Spend a moment thinking about how risk response planning might lead to updates to the schedule, cost, quality, procurements, communications, human resource management plans, and the project's scope, time, and cost baselines.
# General Tips
Actions being taken to control the risk of the project are:
* Look for the occurrence of risk triggers;
* Monitor residual risks;
* Identify new risks and then analyze and plan for them;
* Evaluate the effectiveness of the risk management plan;
* Develop new risk responses;
* Collect and communicate risk status;
* Communicate with stakeholders about risks;
* Determine if assumptions are still valid;
* Ensure proper risk management procedures are being followed;
* Look for any unexpected effects or consequences of risk events;
* Reevaluate risk identification and qualitative & quantitative risk analysis when the project deviates from the baseline;
* Recommend corrective actions to adjust to the severity of actual risk events;
* Use contingency reserves and adjust for approved changes.
Before estimating the project's budget, creating a risk register with stakeholders and evaluating risks is recommended.
Make sure to check the risk register periodically and update it with relevant information.
# Risk Management In Units
## [Unit 1](https://docs.google.com/spreadsheets/d/1ZtiR2qQdcA1yl95kKICqdqj5AfsbWYZ16Fj-Rabqwg8/edit#gid=1335653704)
* DA
* EFL
* IME
* Keller Interiors
* Strada
* TrueTeam
* UnCut
## [Unit 2](https://docs.google.com/spreadsheets/d/10IGlIfJ3ptA1DewhaCsm9M6bh7Sn8h9gNTySvyDdxow/edit#gid=1363908284)
* PyramydAir
* PA Marketplace
* PA Infrastructure
* PA BadaBang
* GBS Ent
* AMTS
* General Devices
## Unit 3
* [EMS](https://docs.google.com/spreadsheets/d/1uwaK0xquc8K1n6Vwia5cQWVvAhyWIZZF/edit#gid=1763422250)
* [Sharable](https://docs.google.com/spreadsheets/d/1YeR-EaRwxDKKJ_RDYbnSKh5wsJ7DbrriAv9C8AMfIF0/edit#gid=1363908284)
## [Unit 4](https://docs.google.com/spreadsheets/d/1-0MGi1C8n-oMo5nmrRXq-xvybQIbhSKaZ3GkgscSrAI/edit#gid=1523500687)
* ASME
* HS Auctions
* SureTrak
## Unit 5
* [JNS](https://docs.google.com/spreadsheets/d/1oNw7iSrkiEwJnxbJ62xcea79B5GvYnz-2Mbz3cvMVwk/edit#gid=322521081)
# Root Cause Analysis
[Ukrainian version of this guideline](https://docs.google.com/document/d/1Ge9QW0g5jw7yV5sbOrcMcNoJ_edojGTD2Z2wGiOoTV8/edit?usp=share_link)
A root cause is defined as a factor that causes nonconformance and should be permanently eliminated through process improvement. The root cause is the core issue - the highest-level cause that sets in motion the entire cause-and-effect reaction that ultimately leads to the problem(s).
Find the [**Template here**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7202)
TEXT in **_bold_** **_italic orange (_****_including links in_** **_light blue_****_)_** is meant to be adopted by each project.
Root cause analysis (RCA) is defined as a collective term that describes a wide range of approaches, tools, and techniques used to uncover the causes of problems.
# Guideline
Once the problem occurs, a root cause can usually be readily identified and properly handled.
## Steps
When conducting a successful root cause analysis, the more participants who can contribute you have, the better. Plan the sequence of activities and execute the steps below in the shortest period of time.
### Step 1: Define the Issue
* What kind of issue do we see?
* What are the specific symptoms?
* Can we locate the causes?
### Step 2: Collect Data
* Do we have as much data and inputs as possible?
* How long has the issue existed?
* What is the impact and severity of the issue?
### Step 3: Identify Possible Causal Factors
* What sequence of events leads to the issue?
* What are the conditions that allow the issue to occur?
### Step 4: Identify the Root Cause
* Why does the causal factor exist?
* What is the real reason the issue occurred?
### Step 5: Plan and Implement Solutions
* Is a solution easy to find and apply asap?
* Shall we apply a temporary fix or do the hard fix right away?
* Is there a plan to monitor the stability of that fix?
* What can you do to prevent the issue from happening again?
* What are the risks of implementing the solution?
Clients must be informed about the process throughout the timeline until the issue is resolved. See the email chain samples below.
1. **Subject:** _Emergency Maintenance / Stability issues_
Yesterday/Today, we had some latency/timeout issues on one of our instances that caused **__** outage. Although we were able to mitigate some of these issues through **__**, we have determined that we need to **__**.
An additional notification will follow with details regarding the related production changes. That notification will only be sent to clients that are impacted. The production changes will be performed during non-business hours.
If you have any questions or concerns, please feel free to reach out to our support team.
Thank you
2. **Subject:** _Maintenance (UPDATE)_
While the team continues to work on the issue, we have observed that **__** is beginning to return to normal. Additionally, we can confirm that our **__** is back online. We will provide you with updates as we progress through the rest of the process.
3. **Subject**: _Intermittent API errors_
We're aware that the API continues to see irregular connections and errors. Our team is monitoring and working to stabilize connections.
We regret this inconvenience and will provide another update in the next **_48_** hours.
Thank you
4. **Subject**: _UPDATE: Intermittent errors_
We are still actively investigating this outage as we continue to see issues with **__** errors. Please hold on using **__** feature/tool.
An update will be provided within the next **_48_** hours.
Thank you
5. **Subject**: _RCA of_ **__** _Outage (#1)_
Dear **__**,
The attached file contains the root cause analysis (RCA) for the Production outage which occurred on **__**. Technical information can also be found within that report.
Please let us know if you need any further assistance.
Thank you
**OR**
**Subject**: _RCA of_ **__** _Outage_ _(#2)_
Dear **__**,
The information below is the root cause analysis (RCA) for the Production outage which occurred on **__**.
Please let us know if you need any further assistance in replying to **__**.
Thank you
The description in the emails to clients must contain the following information:
* general overview
* technical review
* current status
# Security Protocols
[Ukrainian version of this guideline](https://docs.google.com/document/d/1eHEtVNgLmeTDx7TfI1SWVPxAihPFdVsB2TXeoMLMKKQ/edit?usp=share_link)
This guide seeks to ensure that IT resources efficiently serve the primary business functions, provide security for stakeholders’ electronic data, and comply with the basic requirements of cyber security.
The overriding goal of the security policy is to comply with regulatory standards and to protect the integrity of the private and confidential member and business data that resides within the business’s technology infrastructure.
# Prohibited Activities
The following activities are prohibited by employees, with no exceptions:
* Violations of the rights of any person or company protected by copyright, trade secret, patent, or other intellectual property, or similar laws or regulations, including, but not limited to, the installation or distribution of “pirated” or other software products that are not appropriately licensed for use by Devcom
* Unauthorized copying of copyrighted material, including, but not limited to, digitization and distribution from copyrighted sources and the installation of any copyrighted software for which Devcom or the employees does not have an active license, is prohibited. Employees must report unlicensed copies of installed software to **Tech Support** admins
* Introduction of malicious programs into the network or server (e.g., viruses, worms, Trojan horses, e-mail bombs, etc.)
* Revealing account passwords to others or allowing the use of any account by others. This includes family and other household members when work is being done at home
* Using a Devcom computing asset to actively engage in procuring or transmitting material that violates sexual harassment or hostile workplace laws
* Attempting to access any data, electronic content, or programs contained on Devcom systems for which they do not have authorization, explicit consent, or implicit need for their job duties
* Installing any software, upgrades, updates, or patches on any computer or information system without the prior consent of **Tech Support**
* Installing or using non-standard shareware or freeware software without **Tech Support** approval
* Installing, disconnecting, or moving any Devcom-owned computer equipment and peripheral devices without the prior consent of AM, PM, CTO, or **Tech Support**
* Purposely engaging in activities that may:
* degrade the performance of information systems
* deprive an authorized Devcom user's access to company resources
* obtain extra resources beyond those allocated; or
* circumvent Devcom computer security measures.
* Downloading, installing, or running security programs or utilities that reveal passwords, private information, or exploit weaknesses in the security of a system. For example, Devcom employees must not run spyware, adware, password-cracking programs, packet sniffers, port scanners, or any other non-approved programs. **Tech Support** is the only department authorized to perform such actions
* Circumventing user authentication or security of any host, network, or account
* Interfering with, or denying service to, any user other than the employee’s host (for example, denial of service attack)
* Using any program/script/command, or sending messages of any kind, with the intent to interfere with or disable a user’s terminal session via any means, locally or via the Internet/Intranet/Extranet
* Violate the 'clean desk' attributes such as keeping sensitive information recorded in physical items, such as notepads and paperwork, and leaving them unattended; leave the workplace without locking the computer account or any other device.
# Device Policy
[Ukrainian version of this guideline](https://docs.google.com/document/d/1ycXFFvioQBojOc3ZWFumuf7YwpKQO_vTHleM7D7WhH0/edit?usp=share_link)
This guide applies to all Devcom employees, including full and part-time staff, Board of Directors, volunteers, contractors, freelancers, and other agents who utilize any devices to access, store, back up, relocate or access any organization or member-specific data. Such access to this confidential data is a privilege, not a right, and forms the basis of the trust Devcom has built with its members, suppliers, and other constituents.
Consequently, employment at Devcom does not automatically guarantee the initial and ongoing ability to use devices to gain access to corporate networks and information.
# Guideline
The employee understands and agrees to the following:
* The employee is responsible for securing the equipment provided to the employee by Devcom's **Tech Support** Department.
* This equipment is the sole and exclusive property of Devcom.
* With the exception of normal wear and tear, the employee is liable for the condition of the equipment and for any damages caused by any misuse, negligence, and/or unauthorized use of the equipment.
* The employee will not modify any Devcom equipment without written authorization from the **Tech Support** Department.
* In the event of equipment failure, the employee will notify the **Tech Support** Department as soon as possible. Devcom may supply temporary equipment in the event of equipment failure.
* All of Devcom's equipment is provided exclusively for use in providing services to Clients.
* Personally owned equipment may be connected to the owned equipment in case of AM's approval.
* Within five (**5**) business days after the termination of employment at Devcom, the employee shall return all supplied equipment to the IT Department. If it should become necessary for Devcom to resort to legal or other means to recover its equipment, the employee agrees to pay all related costs and attorneys’ fees that may be incurred by Devcom.
Tech Department reserves the right to:
* Install anti-virus software on any company-owned device OR personal device if it is used during work.
* Restrict using some applications.
* Limit the use of network resources.
* Wipe data on lost/damaged devices or upon the termination of employment.
* Properly perform job provisioning and configuration of equipment before connecting to the network.
* Through policy enforcement and any other means, it deems necessary to limit the ability of end-users to transfer data to and from specific resources on the Devcom network.
* Devcom may offer reimbursement of expenses to employees if they choose to use their own devices in lieu of accepting a company-issued device.
# WI-FI Policy
[Ukrainian version of this guideline](https://docs.google.com/document/d/1WeizEWvRTJ86dYJ6IMyXMLUAnCCinlly8g99QEFgOk0/edit#heading=h.jt0gss7onm7t)
This guide seeks to secure and protect the information assets owned by Devcom and to establish awareness and safe practices for connecting to free and unsecured Wi-Fi networks. Devcom's **Tech Support** grants access to these resources as a privilege and must manage them responsibly to maintain the confidentiality, integrity, and availability of all information assets.
# Guideline
## Company/Home Wi-Fi
The Wi-Fi network and connection to the Internet at work or when working from home must be:
* Secured with a passcode and encryption, in accordance with current industry practice:
* No less than 8 symbols
* Must contain at least 1 special character
* Must contain at least 1 capital letter
* Must not have common words or number combos (e.g. tree, password, 12345, etc.).
* Passcodes are of appropriate complexity and changed at designed intervals (once in a Quarter).
* Physically or logically separate from the Devcom's production wired local area network (LAN) and its resources.
* Provide a separate network as a convenience for the use of Devcom's visitors, Clients while visiting offices, and employees when using the internet for other than work purposes.
* Use for access to the Devcom production LAN only for business use and with the approved use of a **Tech Support** issued virtual private network (VPN) connection, especially when working from home.
* Devcom’s Wi-Fi service may be changed, the passcode re-issued or rescinded, the network made unavailable, or otherwise removed without notice for the security or sustainability of Devcom's business.
## Public Wi-Fi
When using Wi-Fi in public places, there are precautions that should be followed:
* As with any Internet-connected device, defend your laptop, tablet, phone, etc. against Internet threats. Make sure a computer or device has the latest antivirus software, turned on firewall, never perform a download on a public Internet connection, and use strong passwords.
* Look around before selecting a place to sit, consider a seat with your back to a wall and position your device so that someone nearby cannot easily see the screen.
* Assume all Wi-Fi links are suspicious, so choose a connection carefully. A rogue wireless link may have been set up by a malefactor. Actively choose the one that is known to be the network you expect and have reason to trust.
* Try to confirm that a given Wi-Fi link is legitimate. Check the security level of the network by choosing the most secure connection, even if you have to pay for access. A password-protected connection (one that is unique for your use) is better than one with a widely shared passcode and infinitely better than one without a passcode.
* Consider that one of two similar-appearing SSIDs or connection names may be rogue and could have been setup by a malefactor. Inquire of the manager of the establishment for information about their official Wi-Fi access point.
* Avoid free Wi-Fi with no encryption. Even if your website or other activity is using https (with a lock symbol in your browser) or other secure protocols, you are at much greater risk of snooping, eavesdropping, and hacking when on an open Wi-Fi connection (such as at Starbuck’s, McDonald’s, some hotels, etc.).
* Seek out Wi-Fi connections that use current industry-accepted encryption methods and that generally will require the obtaining of a passphrase from the establishment.
* Consider using your cell phone data plan for sensitive activities rather than untrusted Wi-Fi, or your own mobile hotspot if you have one or have been provided with one.
* If you must use an open Wi-Fi, do not engage in high-risk transactions or highly- confidential communication without first connecting to a virtual private network (VPN).
* If sensitive information absolutely must be entered while using a public network, limit your activity and make sure that, at a minimum, your web browser connection is encrypted with the locked padlock icon visible in the corner of the browser window, and make sure the web address begins with https://. If possible, save your financial transactions for when you are on a trusted and secured connection, at home, for instance. Passwords, credit card numbers, online banking logins, and other financial information is less secure on a public network.
* Avoid visiting sites that can make it easier or more tempting for malefactors to steal your data (for example, banking, social media, and any site where your credit card information is stored).
* In general, turn off your wireless network on your computer, tablet, or phone when you are not using it to prevent automatic connection to open and possibly dangerous IPs. Set your device to not connect automatically to public or unknown and untrusted networks.
* Do not leave your device unattended, not even for a moment. Your device may be subject to loss or theft, and even if it is still where you left it, a thief could have installed a keylogger to capture your keystrokes or other malware to monitor or intercept the device or connection.
* Do not email or originate other messages of a confidential nature or conduct banking or other sensitive activities, and definitely not when connected to an open, unencrypted Wi-Fi.
* Do not allow automatic connection to or connection to first Wi-Fi IP your device finds, as it may be a rogue IP set up by a thief. Rather, choose the one that is known to be the network you expect and have reason to trust.
# Password Policy
[Ukrainian version of this guideline](https://docs.google.com/document/d/11QYcMAJIGLBb19VJLXh-PeMoz4vNwEdS9TwmWyCVQdI/edit?usp=sharing)
The purpose of this guide is to establish a standard for the creation of strong passwords, the protection of those passwords, and their frequency of change.
This policy applies to all employees who have, or are responsible for, an account (or any form of access that supports or requires a password) on any system that resides at any Devcom facility, has access to the company network, or stores any non-public Devcom's information.
# User Network Passwords
Passwords for Devcom network access must be implemented according to the following guidelines:
* Passwords must be changed every 90 days
* Passwords must adhere to a minimum length of 8 characters
* Passwords must contain a combination of alpha, numeric, and special characters, where the computing system permits (!@#$%^&\*\_+=?/~’;’,<>|\\).
* Passwords must not be easily tied back to the account owner, such as:
* username
* personal ID (driver's license, passport)
* nickname
* relative’s names
* birth date
* Passwords must not be dictionary words or acronyms
* Passwords cannot be reused for 1 year
# System-Level Passwords
All system-level passwords must adhere to the following guidelines:
* Passwords must be changed at least every 6 months
* All administrator accounts must have 12-character passwords which must contain three of the four items: upper case, lower case, numbers, and special characters
* Non-expiring passwords must be documented listing the requirements for those accounts. These accounts need to adhere to the same standards as administrator accounts
* Administrators must not circumvent the Password Policy for the sake of ease of use
* Non-expiring passwords or rarely-changed passwords can be shared with authorized employees only and through special tools without disclosing passwords
# Password Protection
* The same password must not be used for multiple accounts
* Passwords must not be shared with anyone. All passwords are to be treated as sensitive, confidential Devcom information
* Stored passwords must be encrypted
* Passwords must not be inserted in e-mail messages or other forms of electronic communication
* Passwords must not be revealed over the phone to anyone
* Passwords must not be revealed on questionnaires or security forms
* Users must not hint at the format of a password (for example, “my family name”)
* Devcom passwords must not be shared with anyone, including co-workers, managers, or family members, while on vacation
* Passwords must not be written down and stored anywhere in any office. Passwords must not be stored in a file on a computer system or mobile device (phone, tablet) without encryption
* If the security of an account is in question, the password must be changed immediately. In the event passwords are found or discovered, the following steps must be taken:
* Take control of the passwords and protect them
* Report the discovery to IT
* Users cannot circumvent password entry with auto logon, application remembering, embedded scripts, or hard-coded passwords in client software. Exceptions may be made for specific applications (like automated backup processes) with the approval of AM/Tech Lead
* PCs must not be left unattended without enabling a password-protected screensaver or logging off the device
* Security tokens (i.e. smartcards, RSA hardware tokens, etc.) must be returned upon demand or upon the termination of the relationship with Devcom.
# VPN Policy
[Ukrainian version of this guideline](https://docs.google.com/document/d/1RVuQXf-yogy5G4jXpeKg7Cc2GgWs3DmYB2jiVbprwJw/edit?usp=sharing)
The purpose of this guide is to define standards for connecting to Devcom’s network from any host. These standards are designed to minimize the potential exposure to Devcom from damages that may result from the unauthorized use of Devcom resources.
# Guideline
* All remote access to Devcom will either be through a secure VPN connection on a Devcom-owned device that has up-to-date anti-virus software or on approved mobile devices.
* Users must not extend or re-transmit network services in any way. This means a user must not install a router, switch, hub, or wireless access point to the Devcom network without **Tech Support** approval.
* Users must not install network hardware or software that provides network services without **Tech Support** approval. Non-Devcom computer systems that require network connectivity must be approved by **Tech Support**.
* Users must not download, install, or run security programs or utilities that reveal weaknesses in the security of a system. For example, Devcom employees and users must not run password-cracking programs, packet sniffers, network mapping tools, or port scanners while connected in any manner to the Devcom network infrastructure. Only **Tech Support** is permitted to perform these actions.
* Users are not permitted to alter network hardware in any way.
* Reconfiguration of a home user’s equipment for split-tunneling or dual-homing is not permitted at any time.
* It is the responsibility of employees, contractors, vendors, and agents with remote access privileges to Devcom’s corporate network to ensure that their remote access connection is given the same consideration as the user’s on-site connection.
# Rules
* VPN use is controlled using the MFA (multifactor authentication).
* When actively connected to the corporate network, VPNs will force all traffic to and from the PC over the VPN tunnel; all other traffic will be dropped.
* VPN gateways will be set up and managed by Devcom.
* All computers connected to Devcom internal networks via VPN or any other technology must use up-to-date anti-virus software applicable to that device or platform.
* VPN users will be automatically disconnected from Devcom’s network after **thirty (30) minutes** of inactivity. The user must then log on again to reconnect to the network. Pings or other artificial network processes are not to be used to keep the connection open.
* The VPN concentrator is limited to an absolute connection time of **24 hours**.
* Only **Tech Support** VPN clients may be used.
* By using VPN technology, users understand that PCs and laptops are an extension of Devcom’s network and, as such, are subject to the same rules and regulations, as well as monitoring for compliance with this policy.
* All computers with wireless LAN devices must utilize a Devcom-approved VPN configured to drop all unauthenticated and unencrypted traffic and will be provisioned with split-tunneling disabled. As with all Devcom computers, Windows, macOS, or other OS and/or browsers, Internet proxy settings will be enabled to effectively route Internet access to the device through Devcom firewalls and Internet filters.
* To comply with this policy, wireless implementations must maintain point-to-point hardware encryption of at least 128 bits, support a hardware address that can be registered and tracked (i.e., a MAC address), and support and employ strong user authentication which checks against an external database such as TACACS+, iDiTJS, or similar.
# Firewall Policy
[Ukrainian version of this guideline](https://docs.google.com/document/d/1vsJuY9GH2uviptHMWip1FVuZxiq3HwJU2QPAkwF40bw/edit#)
This guide governs how the firewalls will filter Internet traffic to mitigate the risks and losses associated with security threats to Devcom’s network and information systems.
# The Firewall Security Services
* Access control between the trusted internal network and untrusted external networks
* Block unwanted traffic as determined by the firewall ruleset
* Hide vulnerable internal systems from the Internet
* Hide information, such as system names, network topologies, and internal user IDs, from the Internet
* Log traffic to and from the internal network
* Support virtual private network (VPN) connectivity
* Prevent IP spoofing attacks - the creation of IP packets with a forged source IP address with the purpose of concealing the identity of the sender or impersonating another computing system
* Prevent Denial-of-Service (DoS) attacks - the goal is to flood the victim with overwhelming amounts of traffic, and the attacker does not care about receiving responses to the attack packets
* Protect any network information utility that would reveal information about the Devcom commercial and private data.
**Tech Support** must review all network firewall rulesets and configurations during the initial implementation process and quarterly thereafter. Access to rulesets and configurations and backup media must be restricted to those responsible for administration and review.
# Anti-virus Policy
[Ukrainian version of this guideline](https://docs.google.com/document/d/1wFm8V8NuAPJkS_IRmbw5YLK6l5l8ek4kgO7lci59YHc/edit#)
This guide helps to prevent infection of Devcom computers, networks, and technology systems from malware and other malicious code, and prevent damage to user applications, data, files, and hardware.
# Guideline
All computer devices connected to the Devcom network and networked resources shall have anti-virus software installed and configured so that the virus definition files are current and are routinely and automatically updated. The anti-virus software must be actively running on these devices.
* The virus protection software must not be disabled or bypassed without **Tech Support** approval
* The settings for the virus protection software must not be altered in a manner that will reduce the effectiveness of the software
* The automatic update frequency of the virus protection software must not be altered to reduce the frequency of updates
* Each file server attached to the Devcom network must utilize **Tech Support**\-approved virus protection software and be set up to detect and clean viruses that may infect Devcom resources
* Each e-mail gateway must utilize **Tech Support**\-approved e-mail virus protection software
* All files on computer devices will be scanned periodically for malware
* Every virus that is not automatically cleaned by the virus protection software constitutes a security incident and must be reported to **Tech Support** admins
* If deemed necessary to prevent propagation to other networked devices or detrimental effects to the network or data, an infected computer device may be disconnected from the Devcom network until the infection has been removed.
# Employees Manual
* Avoid viruses by never opening any files or macros attached to an e-mail from an unknown, suspicious, or untrustworthy source. Delete these attachments immediately, then remove them from the Trash or Recycle Bin
* Delete spam, chain, or other junk mail without opening or forwarding the item
* Never download files from unknown or suspicious sources
* Always scan removable media from an unknown or non-Devcom source (memory card or USB from a vendor) for viruses before using it
* Back up critical data on a regular basis and store the data in a safe place. Critical Devcom data can be saved to network drives/cloud accounts and are backed up on a periodic basis
* Because new viruses are discovered every day, users should periodically check the Anti-Virus Policy for updates.
# Vulnerabilities
## Virus
A program that attaches itself to an executable file or vulnerable application and delivers a payload that ranges from annoying to extremely destructive. A file virus executes when an infected file is accessed. A macro virus infects the executable code embedded in software such as Microsoft Office programs and Google spreadsheets (unpublished plugins from other than the official web store) that allow users to generate macros.
## Trojan Horse
Destructive programs, usually viruses or worms, are hidden in an attractive or innocent-looking piece of software, such as a game or graphics program. Victims may receive a Trojan horse program by e-mail or removable media, often from another unknowing victim, or may be urged to download a file from a website or download site (pop-up windows).
## Worm
A program that makes copies of itself elsewhere in a computing system. These copies may be created on the same computer or may be sent over networks to other computers. Some worms are security threats using networks to spread themselves against the wishes of the system owners and disrupt networks by overloading them. A worm is similar to a virus in that it makes copies of itself but different in that it need not attach to particular files or sectors at all.
## Spyware
Programs that install and gather information from a computer without permission and report the information to the creator of the software or to one or more third parties.
## Malware
Short for malicious software, a program or file that is designed to specifically damage or disrupt a system, such as a virus, worm, or Trojan horse.
## Adware
Programs that are downloaded and installed without the user’s consent or bound with other software to conduct commercial advertisement propaganda through pop-ups or other ways often lead to system slowness or exceptions after installation.
## Keyloggers
A computer program that captures the keystrokes of a computer user and stores them. Modern keyloggers can store additional information, such as images of the user’s screen. Most malicious keyloggers send this data to a third party remotely (such as via email).
## Ransomware
A type of malware that prevents or limits users from accessing their system, either by locking the system's screen or by locking the users' files, encrypting them, and possibly destroying them unless a ransom is paid.
# Sensitive Information
# Sensitive Information
Sensitive information is data that must be protected from unauthorized access to safeguard the privacy or security of an individual or organization.
There are three main types of sensitive information:
* Personal
* Business
* Classified
# Personal Information
Sensitive personally identifiable information (PII) is data that can be traced back to an individual and that, if disclosed, could result in harm to that person. Threats include not only crimes such as identity theft but also disclosure of personal information that the individual would prefer to remain private. Sensitive PII should be encrypted both in transit and at rest. Such information includes biometric data, medical information (Personal Health Information - PHI), personally identifiable financial information (PIFI) along with Payment Card Industry Standards (PCI), and unique identifiers such as passport or Social Security numbers.
## Personally Identifiable Information ([PII](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-10080))
**Personally identifiable information (PII)** is any representation of information that permits an individual's identity to whom the information applies to be reasonably inferred by either direct or indirect means. Further, PII is defined as information:
\- that directly identifies an individual (e.g., name, address, social security number or other identifying number or code, telephone number, email address, etc.) or
\- by which an agency intends to identify specific individuals in conjunction with other data elements, i.e., indirect identification.
These data elements may include a combination of gender, race, birth date, geographic indicator, and other descriptors.
## **Non-Personally Identifiable Information**
**Non-PII** is data that cannot be used on its own to detect, trace, or identify a person. This could be:
* Aggregated statistics on the use of a product or service
* Partially or fully masked IP address
* Generalized data
* Information gathered by government bodies or municipalities, such as census data or tax receipts collected for publicly funded works.
### Certification
[TÜV SÜD](https://www.tuvsud.com/en/services/auditing-and-system-certification/iso-iec-27018-protection-of-personally-identifiable-information-in-public-clouds), [NQA](https://www.nqa.com/en-us/certification/standards/iso-27018) are trusted partners that can audit and verify PII compliance outlined in ISO/IEC 27018:2019.
## Health Insurance Portability And Accountability Act ([HIPAA](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-10041))
The Health Insurance Portability and Accountability Act of 1996, commonly known as HIPAA, is a series of regulatory standards that outline the lawful use and disclosure of protected health information (PHI). Through a series of interlocking regulatory rules, HIPAA compliance is a living culture that health care organizations must implement into their business to protect the privacy, security, and integrity of protected health information.
### Certification
Unlike PCI, no one can “certify” that an organization is HIPAA compliant. The Office for Civil Rights (OCR) from the [U.S. Department of Health and Human Services](http://www.hhs.gov/ocr/privacy/hipaa/understanding/srsummary.html) (HHS) is the federal governing body that determines compliance. HHS does not endorse or recognize the “certifications” made by private organizations.
## Payment Card Industry Standards ([PCI](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-10100))
The Payment Card Industry Data Security Standard (PCI DSS) is a set of security standards formed in 2004 by Visa, MasterCard, Discover Financial Services, JCB International, and American Express. Governed by the Payment Card Industry Security Standards Council (PCI SSC), the compliance scheme secures credit and debit card transactions against data theft and fraud.
### Certification
[PAYSW](https://www.paysw.com/), [TrustWave](http://www.trustwave.com), [Sikich](https://www.sikich.com/technology/cybersecurity/) are trusted partners that can audit and verify PII compliance.
## Children's Online Privacy Protection Act ([COPPA](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-10020))
COPPA imposes certain requirements on operators of websites or online services directed to children under 13 years of age and on operators of other websites or online services that have actual knowledge that they are collecting personal information online from a child under 13 years of age.
See the [last Amendments](https://www.ftc.gov/system/files/2012-31341.pdf) for more information.
### Certification
List of currently approved Safe Harbor organizations:
* [Children’s Advertising Review Unit (CARU)](https://www.ftc.gov/system/files/attachments/press-releases/revised-childrens-online-privacy-protection-rule-goes-effect-today/130701carusafeharborapp.pdf)
* [Entertainment Software Rating Board (ESRB)](https://www.ftc.gov/system/files/attachments/press-releases/entertainment-software-rating-board-awarded-safe-harbor-status/sh_130701esrb_application.pdf)
* [iKeepSafe](https://www.ftc.gov/system/files/attachments/press-releases/ftc-seeks-public-comment-ikeepsafes-proposed-safe-harbor-program-under-childrens-online-privacy/ikeepsafeprogramapp_0.pdf)
* [kidSAFE](https://www.ftc.gov/system/files/attachments/press-releases/ftc-approves-kidsafe-safe-harbor-program/kidsafe_seal_program_certification_rules_ftc-approved_kidsafe_coppa_guidelines_feb_2014.pdf)
* [Privacy Vaults Online, Inc. (d/b/a PRIVO)](https://www.ftc.gov/system/files/attachments/press-releases/revised-childrens-online-privacy-protection-rule-goes-effect-today/130701privosafeharbor.pdf)
* [TRUSTe](https://www.ftc.gov/system/files/attachments/press-releases/ftc-approves-modifications-trustes-coppa-safe-harbor-program/truste_childrencertstandards_031017.pdf)
## System And Organization Controls ([SOC 2](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-10120))
SOC stands for “system and organization controls,” and controls are a series of standards designed to help measure how well a given service organization conducts and regulates its information. SOC standards aim to provide confidence and peace of mind for organizations when they engage third-party vendors.
SOC 2 is an auditing procedure that ensures the service providers securely manage the data to protect the interests of the Client's organization and its clients' privacy. SOC 2 compliance is a minimal requirement for security-conscious businesses when considering a SaaS provider.
### Certification
SOC audits can only be performed by independent CPAs (Certified Public Accountants) or accounting firms.
# Business Information
Sensitive business information includes anything that poses a risk to the company in question if discovered by a competitor or the general public. Such information includes trade secrets, acquisition plans, financial data, and supplier and customer information, among other possibilities. With the ever-increasing amount of data generated by businesses, methods of protecting corporate information from unauthorized access are becoming integral to corporate security. These methods include metadata management and document sanitization.
The confidentiality of sensitive business information is established through thePrivate ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-4061](https://app.clickup.com/8491693/docs/834nd-2241/834nd-4061)), a legally binding contract between two parties in a professional relationship. NDAs may be one-way, such as in the case of an employee receiving confidential information about the employing organization, or two-way between businesses needing to share information with one another to accomplish a business goal. Depending on the severity of consequences, a violation of non-disclosure may result in employment loss, loss of business and client contacts, criminal charges or a civil lawsuit, and a hefty sum in damages.
Unlike PII, there is no internationally recognized framework protecting trade secrets or even an agreed-upon definition of the term “trade secret”. However, many countries and political jurisdictions have taken the initiative to account for the violation of commercial confidentiality in their criminal or civil laws. For example, under the US Economic Espionage Act of 1996, it is a federal crime in the United States to misappropriate trade secrets with the knowledge that it will benefit a foreign power or will injure the owner of the trade secret. More commonly, breach of commercial confidentiality falls under civil law, such as in the United Kingdom.
With that being said, most businesses consider sensitive information to include:
* Trade secrets or intellectual property
* Sales information
* Marketing information
* New product strategy
* Patent documentation
* Partner information
* Commercial and Financial data
* Acquisition plans
**Business Information** may include but is not limited to names, addresses, phone numbers, financial information, bank account and credit card numbers, other employee and student personal information (including their academic record, etc.), Driver’s License and Social Security numbers, in both paper and electronic format.
# Classified Information
Classified information pertains to a government body (social, economic, military purposes) and is restricted according to the level of sensitivity (for example, restricted, confidential, secret, and top-secret). Information is generally classified to protect security. Once the risk of harm has passed or decreased, classified information may be declassified and, possibly, made public.
Classified information access is restricted according to five levels of sensitivity:
1. Top secret
2. Secret
3. Confidential
4. Sensitive unclassified
5. Unclassified - classified information that has been declassified
# Implementation Guide
# Sensitive Information Assessment Process
1. Identify if this project has **Personal**, **Business**, or **Classified** information
1. Who
2. How
3. When
2. Personal, Business, Classified Information Assessment
1. Identify
2. Assess
3. Discuss with stakeholders
4. Approve
5. Convert into a system specification
1. Solution non-functional requirements section
2. Architectural Template
# Identification of Personal, Business, or Classified information
1. **Who**
1. BA
2. optionally Tech Lead and PM
2. **How**
1. Interview stakeholders
2. Review specifications and customer-provided documentation
3. Industry-based knowledge (SMEs, internal resources, other teams)
3. **When**
1. During the business need analysis
2. During the requirements elicitation
3. During the features technical design
4. During the tasks and new milestones planning
## Template
| **STEP** | **RESULT** | **STATUS** |
| ---| ---| --- |
| Select Team | _Name, position_ | _To do, In progress, Done, Ongoing_ |
| Interview stakeholders | | |
| Review specification | _e.g., Not Applicable_ | |
| Business needs analysis | | |
| Requirements elicitation | | |
| Features technical design | | |
| Tasks and new milestones planning | | |
| Security: Firewall, Antivirus protection set up for server(less) | | |
| | | |
# Personal Information Template
* PII
* PIFI, PCI
* PHI, HIPAA
* COPPA
# Business Information
* Trade secrets or intellectual property
* Sales information
* Marketing information
* New product strategy
* Patent documentation
* Partner information
* Commercial and Financial data
* Acquisition plans
# Classified Information
N/A
# Technical Implementation Guide
## Areas of Concern
| **COMPONENT** | **CONCERN** | **SOLUTION** |
| ---| ---| --- |
| Database |
| |
| Files |
| |
| System and application logs |
| |
| Emails |
| |
| Display |
| |
| API/WebPages |
| |
| | | |
# PII Implementation Guide
# PII
- [ ] - [ ] **Identify**
| **PII ELEMENT** | **DESCRIPTION** | **STATUS** |
| ---| ---| --- |
| _Full name_ | First Name, Last Name | _To do, In progress, Done, Ongoing_ |
| _Date of birth_ | Month, Date, Year of birth | |
| _Home address_ | Street number, Street Name, City, State, Country, Zip | |
| _Telephone number_ | Country code, phone number | |
| _Social security number_ | Nine digits | |
| _Passport number_ | Letter(s) and/or nine digits | |
| _Driver’s license number_ | Ten digits | |
| _Credit card details_ | 16 digits, expiration date (month, year), cardholder name, CVV code, magnetic data | |
| _Email address_ | name, @ symbol, domain name | |
| _Owned properties, vehicles_ | Property name, unit number, address (Street number, Street Name, City, State, Country, Zip), year built, dimensions (H, W, L), area (s.ft); vehicle name, VIN code (17 digits and letters), serial model name/number | |
| _Login details_ | Username, password | |
| _Processor or device serial number_ | Letter(s) and/or digits | |
| _Media access control (MAC)_ | 48-bit number | |
| _Internet Protocol (IP) address_ | 32-bit number | |
| _Device IDs_ | Letter(s) and/or digits | |
| _Cookies_ | Name, value, attributes (cookie's expiration, domain, and flags) | |
- [ ] - [ ] **Assess**
| **PII ELEMENT** | **DESCRIPTION** | **ASSESSMENT** | **STATUS** |
| ---| ---| ---| --- |
| _Full name_ | First Name, Last Name | | _To do, In progress, Done, Ongoing_ |
| _Date of birth_ | Month, Date, Year of birth | | |
| _Home address_ | Street number, Street Name, City, State, Country, Zip | | |
| _Telephone number_ | Country code, phone number | | |
| _Social security number_ | Nine digits | | |
| _Passport number_ | Letter(s) and/or nine digits | | |
| _Driver’s license number_ | Ten digits | | |
| _Credit card details_ | 16 digits, expiration date (month, year), cardholder name, CVV code, magnetic data | | |
| _Email address_ | name, @ symbol, domain name | | |
| _Owned properties, vehicles_ | Property name, unit number, address (Street number, Street Name, City, State, Country, Zip), year built, dimensions (H, W, L), area (s.ft); vehicle name, VIN code (17 digits and letters), serial model name/number | | |
| _Login details_ | Username, password | | |
| _Processor or device serial number_ | Letter(s) and/or digits | | |
| _Media access control (MAC)_ | 48-bit number | | |
| _Internet Protocol (IP) address_ | 32-bit number | | |
| _Device IDs_ | Letter(s) and/or digits | | |
| _Cookies_ | Name, value, attributes (cookie's expiration, domain, and flags) | | |
- [ ] - [ ] **Discuss with stakeholders**
| **PII ELEMENT** | **DESCRIPTION** | **ASSESSMENT** | **NOTES** |
| ---| ---| ---| --- |
| _Full name_ | First Name, Last Name | | |
| _Date of birth_ | Month, Date, Year of birth | | |
| _Home address_ | Street number, Street Name, City, State, Country, Zip | | |
| _Telephone number_ | Country code, phone number | | |
| _Social security number_ | Nine digits | | |
| _Passport number_ | Letter(s) and/or nine digits | | |
| _Driver’s license number_ | Ten digits | | |
| _Credit card details_ | 16 digits, expiration date (month, year), cardholder name, CVV code, magnetic data | | |
| _Email address_ | name, @ symbol, domain name | | |
| _Owned properties, vehicles_ | Property name, unit number, address (Street number, Street Name, City, State, Country, Zip), year built, dimensions (H, W, L), area (s.ft); vehicle name, VIN code (17 digits and letters), serial model name/number | | |
| _Login details_ | Username, password | | |
| _Processor or device serial number_ | Letter(s) and/or digits | | |
| _Media access control (MAC)_ | 48-bit number | | |
| _Internet Protocol (IP) address_ | 32-bit number | | |
| _Device IDs_ | Letter(s) and/or digits | | |
| _Cookies_ | Name, value, attributes (cookie's expiration, domain, and flags) | | |
- [ ] - [ ] **Approve**
| **PII ELEMENT** | **DESCRIPTION** | **ASSESSMENT** | **NOTES** | **CLIENT STATUS** |
| ---| ---| ---| ---| --- |
| _Full name_ | First Name, Last Name | | | _To do, In progress, Done, Ongoing_ |
| _Date of birth_ | Month, Date, Year of birth | | | |
| _Home address_ | Street number, Street Name, City, State, Country, Zip | | | |
| _Telephone number_ | Country code, phone number | | | |
| _Social security number_ | Nine digits | | | |
| _Passport number_ | Letter(s) and/or nine digits | | | |
| _Driver’s license number_ | Ten digits | | | |
| _Credit card details_ | 16 digits, expiration date (month, year), cardholder name, CVV code, magnetic data | | | |
| _Email address_ | name, @ symbol, domain name | | | |
| _Owned properties, vehicles_ | Property name, unit number, address (Street number, Street Name, City, State, Country, Zip), year built, dimensions (H, W, L), area (s.ft); vehicle name, VIN code (17 digits and letters), serial model name/number | | | |
| _Login details_ | Username, password | | | |
| _Processor or device serial number_ | Letter(s) and/or digits | | | |
| _Media access control (MAC)_ | 48-bit number | | | |
| _Internet Protocol (IP) address_ | 32-bit number | | | |
| _Device IDs_ | Letter(s) and/or digits | | | |
| _Cookies_ | Name, value, attributes (cookie's expiration, domain, and flags) | | | |
- [ ] - [ ] **Convert into a system specification**
| **PII ELEMENT** | **DESCRIPTION** | **SPECIFICATION** | **STATUS** |
| ---| ---| ---| --- |
| _Full name_ | First Name, Last Name | _Database_
Encrypt the Full\_Name field in all tables
Dev team will not have access to real data only to fake test data
_Files_
Do not store FullName in any of the files related to this project
_Logs_
Do not output FullName in any of the logs instead, output initials where needed
_...._ | _To do, In progress, Done, Ongoing_ |
| _Date of birth_ | Month, Date, Year of birth | | |
| _Home address_ | Street number, Street Name, City, State, Country, Zip | | |
| _Telephone number_ | Country code, phone number | | |
| _Social security number_ | Nine digits | | |
| _Passport number_ | Letter(s) and/or nine digits | | |
| _Driver’s license number_ | Ten digits | | |
| _Credit card details_ | 16 digits, expiration date (month, year), cardholder name, CVV code, magnetic data | | |
| _Email address_ | name, @ symbol, domain name | | |
| _Owned properties, vehicles_ | Property name, unit number, address (Street number, Street Name, City, State, Country, Zip), year built, dimensions (H, W, L), area (s.ft); vehicle name, VIN code (17 digits and letters), serial model name/number | | |
| _Login details_ | Username, password | | |
| _Processor or device serial number_ | Letter(s) and/or digits | | |
| _Media access control (MAC)_ | 48-bit number | | |
| _Internet Protocol (IP) address_ | 32-bit number | | |
| _Device IDs_ | Letter(s) and/or digits | | |
| _Cookies_ | Name, value, attributes (cookie's expiration, domain, and flags) | | |
# Technical Implementation Guide
## Areas of Concern
| **COMPONENT** | **CONCERN** | **SOLUTION** |
| ---| ---| --- |
| Database |
| |
| Files |
| |
| System and application logs |
| |
| Emails |
| |
| Display |
| |
| API/WebPages |
| |
| | | |
| | | |
# PHI+HIPAA Implementation Guide
# PHI + HIPAA
- [ ] - [ ] **Identify**
| **PII ELEMENT** | **DESCRIPTION** | **STATUS** |
| ---| ---| --- |
| _Full name_ | First Name, Last Name | _To do, In progress, Done, Ongoing_ |
| _Date of birth_ | Month, Date, Year of birth | |
| _Home address_ | Street number, Street Name, City, State, Country, Zip | |
| _Telephone number_ | Country code, phone number | |
| _Social security number_ | Nine digits | |
| _Passport number_ | Letter(s) and/or nine digits | |
| _Driver’s license number_ | Ten digits | |
| _Credit card details_ | 16 digits, expiration date (month, year), cardholder name, CVV code, magnetic data | |
| _Login details_ | Username, password | |
| _Email address_ | name, @ symbol, domain name | |
| _Medical records_ | List of illnesses, start and end dates of illnesses, list of surgeries, list of prescribed medication, list of diagnoses | |
| _Billing information_ | Street number, Street Name, City, State, Country, Zip | |
| _Financial information_ | Bank name, account number, routing number, ACH, SWIFT code, beneficiary name, EIN | |
| _Full facial photos_ | Patient's photo | |
| _Processor or device serial number_ | Letter(s) and/or digits | |
| _Media access control (MAC)_ | 48-bit number | |
| _Internet Protocol (IP) address_ | 32-bit number | |
| _Device IDs_ | Letter(s) and/or digits | |
| _Cookies_ | Name, value, attributes (cookie's expiration, domain, and flags) | |
- [ ] - [ ] **Assess**
| **PII ELEMENT** | **DESCRIPTION** | **ASSESSMENT** | **STATUS** |
| ---| ---| ---| --- |
| _Full name_ | First Name, Last Name | | _To do, In progress, Done, Ongoing_ |
| _Date of birth_ | Month, Date, Year of birth | | |
| _Home address_ | Street number, Street Name, City, State, Country, Zip | | |
| _Telephone number_ | Country code, phone number | | |
| _Social security number_ | Nine digits | | |
| _Passport number_ | Letter(s) and/or nine digits | | |
| _Driver’s license number_ | Ten digits | | |
| _Credit card details_ | 16 digits, expiration date (month, year), cardholder name, CVV code, magnetic data | | |
| _Login details_ | Username, password | | |
| _Email address_ | name, @ symbol, domain name | | |
| _Medical records_ | List of illnesses, start and end dates of illnesses, list of surgeries, list of prescribed medication, list of diagnoses | | |
| _Billing information_ | Street number, Street Name, City, State, Country, Zip | | |
| _Financial information_ | Bank name, account number, routing number, ACH, SWIFT code, beneficiary name, EIN | | |
| _Full facial photos_ | Patient's photo | | |
| _Processor or device serial number_ | Letter(s) and/or digits | | |
| _Media access control (MAC)_ | 48-bit number | | |
| _Internet Protocol (IP) address_ | 32-bit number | | |
| _Device IDs_ | Letter(s) and/or digits | | |
| _Cookies_ | Name, value, attributes (cookie's expiration, domain, and flags) | | |
- [ ] - [ ] **Discuss with stakeholders**
| **PII ELEMENT** | **DESCRIPTION** | **ASSESSMENT** | **NOTES** |
| ---| ---| ---| --- |
| _Full name_ | First Name, Last Name | | |
| _Date of birth_ | Month, Date, Year of birth | | |
| _Home address_ | Street number, Street Name, City, State, Country, Zip | | |
| _Telephone number_ | Country code, phone number | | |
| _Social security number_ | Nine digits | | |
| _Passport number_ | Letter(s) and/or nine digits | | |
| _Driver’s license number_ | Ten digits | | |
| _Credit card details_ | 16 digits, expiration date (month, year), cardholder name, CVV code, magnetic data | | |
| _Login details_ | Username, password | | |
| _Email address_ | name, @ symbol, domain name | | |
| _Medical records_ | List of illnesses, start and end dates of illnesses, list of surgeries, list of prescribed medication, list of diagnoses | | |
| _Billing information_ | Street number, Street Name, City, State, Country, Zip | | |
| _Financial information_ | Bank name, account number, routing number, ACH, SWIFT code, beneficiary name, EIN | | |
| _Full facial photos_ | Patient's photo | | |
| _Processor or device serial number_ | Letter(s) and/or digits | | |
| _Media access control (MAC)_ | 48-bit number | | |
| _Internet Protocol (IP) address_ | 32-bit number | | |
| _Device IDs_ | Letter(s) and/or digits | | |
| _Cookies_ | Name, value, attributes (cookie's expiration, domain, and flags) | | |
- [ ] - [ ] **Approve**
| **PII ELEMENT** | **DESCRIPTION** | **ASSESSMENT** | **NOTES** | **CLIENT STATUS** |
| ---| ---| ---| ---| --- |
| _Full name_ | First Name, Last Name | | | _To do, In progress, Done, Ongoing_ |
| _Date of birth_ | Month, Date, Year of birth | | | |
| _Home address_ | Street number, Street Name, City, State, Country, Zip | | | |
| _Telephone number_ | Country code, phone number | | | |
| _Social security number_ | Nine digits | | | |
| _Passport number_ | Letter(s) and/or nine digits | | | |
| _Driver’s license number_ | Ten digits | | | |
| _Credit card details_ | 16 digits, expiration date (month, year), cardholder name, CVV code, magnetic data | | | |
| _Login details_ | Username, password | | | |
| _Email address_ | name, @ symbol, domain name | | | |
| _Medical records_ | List of illnesses, start and end dates of illnesses, list of surgeries, list of prescribed medication, list of diagnoses | | | |
| _Billing information_ | Street number, Street Name, City, State, Country, Zip | | | |
| _Financial information_ | Bank name, account number, routing number, ACH, SWIFT code, beneficiary name, EIN | | | |
| _Full facial photos_ | Patient's photo | | | |
| _Processor or device serial number_ | Letter(s) and/or digits | | | |
| _Media access control (MAC)_ | 48-bit number | | | |
| _Internet Protocol (IP) address_ | 32-bit number | | | |
| _Device IDs_ | Letter(s) and/or digits | | | |
| _Cookies_ | Name, value, attributes (cookie's expiration, domain, and flags) | | | |
- [ ] - [ ] **Convert into a system specification**
| **PII ELEMENT** | **DESCRIPTION** | **SPECIFICATION** | **STATUS** |
| ---| ---| ---| --- |
| _Full name_ | First Name, Last Name | _Database_
Encrypt the Full\_Name field in all tables
Dev team will not have access to real data only to fake test data
_Files_
Do not store FullName in any of the files related to this project
_Logs_
Do not output FullName in any of the logs instead, output initials where needed
_...._ | _To do, In progress, Done, Ongoing_ |
| _Date of birth_ | Month, Date, Year of birth | | |
| _Home address_ | Street number, Street Name, City, State, Country, Zip | | |
| _Telephone number_ | Country code, phone number | | |
| _Social security number_ | Nine digits | | |
| _Passport number_ | Letter(s) and/or nine digits | | |
| _Driver’s license number_ | Ten digits | | |
| _Credit card details_ | 16 digits, expiration date (month, year), cardholder name, CVV code, magnetic data | | |
| _Login details_ | Username, password | | |
| _Email address_ | name, @ symbol, domain name | | |
| _Medical records_ | List of illnesses, start and end dates of illnesses, list of surgeries, list of prescribed medication, list of diagnoses | | |
| _Billing information_ | Street number, Street Name, City, State, Country, Zip | | |
| _Financial information_ | Bank name, account number, routing number, ACH, SWIFT code, beneficiary name, EIN | | |
| _Full facial photos_ | Patient's photo | | |
| _Processor or device serial number_ | Letter(s) and/or digits | | |
| _Media access control (MAC)_ | 48-bit number | | |
| _Internet Protocol (IP) address_ | 32-bit number | | |
| _Device IDs_ | Letter(s) and/or digits | | |
| _Cookies_ | Name, value, attributes (cookie's expiration, domain, and flags) | | |
# Technical Implementation Guide
## Areas of Concern
| **COMPONENT** | **CONCERN** | **SOLUTION** |
| ---| ---| --- |
| Database |
| |
| Files |
| |
| System and application logs |
| |
| Emails |
| |
| Display |
| |
| API/WebPages |
| |
| | | |
| | | |
# PIFI+PCI Implementation Guide
# PIFI + PCI
- [ ] - [ ] **Identify**
| **PII ELEMENT** | **DESCRIPTION** | **STATUS** |
| ---| ---| --- |
| _Full name_ | First Name, Last Name | _To do, In progress, Done, Ongoing_ |
| _Date of birth_ | Month, Date, Year of birth | |
| _Home address_ | Street number, Street Name, City, State, Country, Zip | |
| _Telephone number_ | Country code, phone number | |
| _Credit card details_ | 16 digits, expiration date (month, year), cardholder name, CVV code, magnetic data | |
| _Billing information_ | Street number, Street Name, City, State, Country, Zip | |
| _Financial information_ | Bank name, account number, routing number, ACH, SWIFT code, beneficiary name, EIN | |
| _Email address_ | name, @ symbol, domain name | |
| _Login details_ | Username, password | |
| _Processor or device serial number_ | Letter(s) and/or digits | |
| _Media access control (MAC)_ | 48-bit number | |
| _Internet Protocol (IP) address_ | 32-bit number | |
| _Device IDs_ | Letter(s) and/or digits | |
| _Cookies_ | Name, value, attributes (cookie's expiration, domain, and flags) | |
- [ ] - [ ] **Assess**
| **PII ELEMENT** | **DESCRIPTION** | **ASSESSMENT** | **STATUS** |
| ---| ---| ---| --- |
| _Full name_ | First Name, Last Name | | _To do, In progress, Done, Ongoing_ |
| _Date of birth_ | Month, Date, Year of birth | | |
| _Home address_ | Street number, Street Name, City, State, Country, Zip | | |
| _Telephone number_ | Country code, phone number | | |
| _Credit card details_ | 16 digits, expiration date (month, year), cardholder name, CVV code, magnetic data | | |
| _Billing information_ | Street number, Street Name, City, State, Country, Zip | | |
| _Financial information_ | Bank name, account number, routing number, ACH, SWIFT code, beneficiary name, EIN | | |
| _Email address_ | name, @ symbol, domain name | | |
| _Login details_ | Username, password | | |
| _Processor or device serial number_ | Letter(s) and/or digits | | |
| _Media access control (MAC)_ | 48-bit number | | |
| _Internet Protocol (IP) address_ | 32-bit number | | |
| _Device IDs_ | Letter(s) and/or digits | | |
| _Cookies_ | Name, value, attributes (cookie's expiration, domain, and flags) | | |
- [ ] - [ ] **Discuss with stakeholders**
| **PII ELEMENT** | **DESCRIPTION** | **ASSESSMENT** | **NOTES** |
| ---| ---| ---| --- |
| _Full name_ | First Name, Last Name | | |
| _Date of birth_ | Month, Date, Year of birth | | |
| _Home address_ | Street number, Street Name, City, State, Country, Zip | | |
| _Telephone number_ | Country code, phone number | | |
| _Credit card details_ | 16 digits, expiration date (month, year), cardholder name, CVV code, magnetic data | | |
| _Billing information_ | Street number, Street Name, City, State, Country, Zip | | |
| _Financial information_ | Bank name, account number, routing number, ACH, SWIFT code, beneficiary name, EIN | | |
| _Email address_ | name, @ symbol, domain name | | |
| _Login details_ | Username, password | | |
| _Processor or device serial number_ | Letter(s) and/or digits | | |
| _Media access control (MAC)_ | 48-bit number | | |
| _Internet Protocol (IP) address_ | 32-bit number | | |
| _Device IDs_ | Letter(s) and/or digits | | |
| _Cookies_ | Name, value, attributes (cookie's expiration, domain, and flags) | | |
- [ ] - [ ] **Approve**
| **PII ELEMENT** | **DESCRIPTION** | **ASSESSMENT** | **NOTES** | **CLIENT STATUS** |
| ---| ---| ---| ---| --- |
| _Full name_ | First Name, Last Name | | | _To do, In progress, Done, Ongoing_ |
| _Date of birth_ | Month, Date, Year of birth | | | |
| _Home address_ | Street number, Street Name, City, State, Country, Zip | | | |
| _Telephone number_ | Country code, phone number | | | |
| _Credit card details_ | 16 digits, expiration date (month, year), cardholder name, CVV code, magnetic data | | | |
| _Billing information_ | Street number, Street Name, City, State, Country, Zip | | | |
| _Financial information_ | Bank name, account number, routing number, ACH, SWIFT code, beneficiary name, EIN | | | |
| _Email address_ | name, @ symbol, domain name | | | |
| _Login details_ | Username, password | | | |
| _Processor or device serial number_ | Letter(s) and/or digits | | | |
| _Media access control (MAC)_ | 48-bit number | | | |
| _Internet Protocol (IP) address_ | 32-bit number | | | |
| _Device IDs_ | Letter(s) and/or digits | | | |
| _Cookies_ | Name, value, attributes (cookie's expiration, domain, and flags) | | | |
- [ ] - [ ] **Convert into a system specification**
| **PII ELEMENT** | **DESCRIPTION** | **SPECIFICATION** | **STATUS** |
| ---| ---| ---| --- |
| _Full name_ | First Name, Last Name | _Database_
Encrypt the Full\_Name field in all tables
Dev team will not have access to real data only to fake test data
_Files_
Do not store FullName in any of the files related to this project
_Logs_
Do not output FullName in any of the logs instead, output initials where needed
_...._ | _To do, In progress, Done, Ongoing_ |
| _Date of birth_ | Month, Date, Year of birth | | |
| _Home address_ | Street number, Street Name, City, State, Country, Zip | | |
| _Telephone number_ | Country code, phone number | | |
| _Credit card details_ | 16 digits, expiration date (month, year), cardholder name, CVV code, magnetic data | | |
| _Billing information_
| Street number, Street Name, City, State, Country, Zip | | |
| _Financial information_ | Bank name, account number, routing number, ACH, SWIFT code, beneficiary name, EIN | | |
| _Email address_ | name, @ symbol, domain name | | |
| _Login details_ | Username, password | | |
| _Processor or device serial number_ | Letter(s) and/or digits | | |
| _Media access control (MAC)_ | 48-bit number | | |
| _Internet Protocol (IP) address_ | 32-bit number | | |
| _Device IDs_ | Letter(s) and/or digits | | |
| _Cookies_ | Name, value, attributes (cookie's expiration, domain, and flags) | | |
# Technical Implementation Guide
## Areas of Concern
| **COMPONENT** | **CONCERN** | **SOLUTION** |
| ---| ---| --- |
| Database |
| |
| Files |
| |
| System and application logs |
| |
| Emails |
| |
| Display |
| |
| API/WebPages |
| |
| | | |
| | | |
# Business Information Implementation Guide
# Business Information
- [ ] - [ ] **Identify**
| **PII ELEMENT** | **DESCRIPTION** | **STATUS** |
| ---| ---| --- |
| _Full name_ | First Name, Last Name | _To do, In progress, Done, Ongoing_ |
| _Date of birth_ | Month, Date, Year of birth | |
| _Home address_ | Street number, Street Name, City, State, Country, Zip | |
| _Telephone number_ | Country code, phone number | |
| _Social security number_ | Nine digits | |
| _Passport number_ | Letter(s) and/or nine digits | |
| _Driver’s license number_ | Ten digits | |
| _Credit card details_ | 16 digits, expiration date (month, year), cardholder name, CVV code, magnetic data | |
| _Billing information_
| Street number, Street Name, City, State, Country, Zip | |
| _Financial information_ | Bank name, account number, routing number, ACH, SWIFT code, beneficiary name, EIN | |
| _Commercial information_
| List of trade secrets, patents or intellectual property, acquisition plans, list of competitors analysis, marketing and sales activities, transactions, contracts terms | |
| _Email address_ | name, @ symbol, domain name | |
| _Owned properties, vehicles_ | Property name, unit number, address (Street number, Street Name, City, State, Country, Zip), year built, dimensions (H,W, L), area (s.ft); vehicle name, VIN code (17 digits and letters), serial model name/number | |
| _Login details_ | Username, password | |
| _Processor or device serial number_ | Letter(s) and/or digits | |
| _Media access control (MAC)_ | 48-bit number | |
| _Internet Protocol (IP) address_ | 32-bit number | |
| _Device IDs_ | Letter(s) and/or digits | |
| _Cookies_ | Name, value, attributes (cookie's expiration, domain, and flags) | |
- [ ] - [ ] **Assess**
| **PII ELEMENT** | **DESCRIPTION** | **ASSESSMENT** | **STATUS** |
| ---| ---| ---| --- |
| _Full name_ | First Name, Last Name | | _To do, In progress, Done, Ongoing_ |
| _Date of birth_ | Month, Date, Year of birth | | |
| _Home address_ | Street number, Street Name, City, State, Country, Zip | | |
| _Telephone number_ | Country code, phone number | | |
| _Social security number_ | Nine digits | | |
| _Passport number_ | Letter(s) and/or nine digits | | |
| _Driver’s license number_ | Ten digits | | |
| _Credit card details_ | 16 digits, expiration date (month, year), cardholder name, CVV code, magnetic data | | |
| _Billing information_ | Street number, Street Name, City, State, Country, Zip | | |
| _Financial information_ | Bank name, account number, routing number, ACH, SWIFT code, beneficiary name, EIN | | |
| _Commercial information_ | List of trade secrets, patents or intellectual property, acquisition plans, list of competitors analysis, marketing and sales activities, transactions, contracts terms | | |
| _Email address_ | name, @ symbol, domain name | | |
| _Owned properties, vehicles_ | Property name, unit number, address (Street number, Street Name, City, State, Country, Zip), year built, dimensions (H,W, L), area (s.ft); vehicle name, VIN code (17 digits and letters), serial model name/number | | |
| _Login details_ | Username, password | | |
| _Processor or device serial number_ | Letter(s) and/or digits | | |
| _Media access control (MAC)_ | 48-bit number | | |
| _Internet Protocol (IP) address_ | 32-bit number | | |
| _Device IDs_ | Letter(s) and/or digits | | |
| _Cookies_ | Name, value, attributes (cookie's expiration, domain, and flags) | | |
- [ ] - [ ] **Discuss with stakeholders**
| **PII ELEMENT** | **DESCRIPTION** | **ASSESSMENT** | **NOTES** |
| ---| ---| ---| --- |
| _Full name_ | First Name, Last Name | | |
| _Date of birth_ | Month, Date, Year of birth | | |
| _Home address_ | Street number, Street Name, City, State, Country, Zip | | |
| _Telephone number_ | Country code, phone number | | |
| _Social security number_ | Nine digits | | |
| _Passport number_ | Letter(s) and/or nine digits | | |
| _Driver’s license number_ | Ten digits | | |
| _Credit card details_ | 16 digits, expiration date (month, year), cardholder name, CVV code, magnetic data | | |
| _Billing information_
| Street number, Street Name, City, State, Country, Zip | | |
| _Financial information_ | Bank name, account number, routing number, ACH, SWIFT code, beneficiary name, EIN | | |
| _Commercial information_
| List of trade secrets, patents or intellectual property, acquisition plans, list of competitors analysis, marketing and sales activities, transactions, contracts terms | | |
| _Email address_ | name, @ symbol, domain name | | |
| _Owned properties, vehicles_ | Property name, unit number, address (Street number, Street Name, City, State, Country, Zip), year built, dimensions (H,W, L), area (s.ft); vehicle name, VIN code (17 digits and letters), serial model name/number | | |
| _Login details_ | Username, password | | |
| _Processor or device serial number_ | Letter(s) and/or digits | | |
| _Media access control (MAC)_ | 48-bit number | | |
| _Internet Protocol (IP) address_ | 32-bit number | | |
| _Device IDs_ | Letter(s) and/or digits | | |
| _Cookies_ | Name, value, attributes (cookie's expiration, domain, and flags) | | |
- [ ] - [ ] **Approve**
| **PII ELEMENT** | **DESCRIPTION** | **ASSESSMENT** | **NOTES** | **CLIENT STATUS** |
| ---| ---| ---| ---| --- |
| _Full name_ | First Name, Last Name | | | _To do, In progress, Done, Ongoing_ |
| _Date of birth_ | Month, Date, Year of birth | | | |
| _Home address_ | Street number, Street Name, City, State, Country, Zip | | | |
| _Telephone number_ | Country code, phone number | | | |
| _Social security number_ | Nine digits | | | |
| _Passport number_ | Letter(s) and/or nine digits | | | |
| _Driver’s license number_ | Ten digits | | | |
| _Credit card details_ | 16 digits, expiration date (month, year), cardholder name, CVV code, magnetic data | | | |
| _Billing information_
| Street number, Street Name, City, State, Country, Zip | | | |
| _Financial information_ | Bank name, account number, routing number, ACH, SWIFT code, beneficiary name, EIN | | | |
| _Commercial information_ | List of trade secrets, patents or intellectual property, acquisition plans, list of competitors analysis, marketing and sales activities, transactions, contracts terms | | | |
| _Email address_ | name, @ symbol, domain name | | | |
| _Owned properties, vehicles_ | Property name, unit number, address (Street number, Street Name, City, State, Country, Zip), year built, dimensions (H,W, L), area (s.ft); vehicle name, VIN code (17 digits and letters), serial model name/number | | | |
| _Login details_ | Username, password | | | |
| _Processor or device serial number_ | Letter(s) and/or digits | | | |
| _Media access control (MAC)_ | 48-bit number | | | |
| _Internet Protocol (IP) address_ | 32-bit number | | | |
| _Device IDs_ | Letter(s) and/or digits | | | |
| _Cookies_ | Name, value, attributes (cookie's expiration, domain, and flags) | | | |
- [ ] - [ ] **Convert into a system specification**
| **PII ELEMENT** | **DESCRIPTION** | **SPECIFICATION** | **STATUS** |
| ---| ---| ---| --- |
| _Full name_ | First Name, Last Name | _Database_
Encrypt the Full\_Name field in all tables
Dev team will not have access to real data only to fake test data
_Files_
Do not store FullName in any of the files related to this project
_Logs_
Do not output FullName in any of the logs instead, output initials where needed
_...._ | _To do, In progress, Done, Ongoing_ |
| _Date of birth_ | Month, Date, Year of birth | | |
| _Home address_ | Street number, Street Name, City, State, Country, Zip | | |
| _Telephone number_ | Country code, phone number | | |
| _Social security number_ | Nine digits | | |
| _Passport number_ | Letter(s) and/or nine digits | | |
| _Driver’s license number_ | Ten digits | | |
| _Credit card details_ | 16 digits, expiration date (month, year), cardholder name, CVV code, magnetic data | | |
| _Billing information_
| Street number, Street Name, City, State, Country, Zip | | |
| _Financial information_ | Bank name, account number, routing number, ACH, SWIFT code, beneficiary name, EIN | | |
| _Commercial information_ | List of trade secrets, patents or intellectual property, acquisition plans, list of competitors analysis, marketing and sales activities, transactions, contracts terms | | |
| _Email address_ | name, @ symbol, domain name | | |
| _Owned properties, vehicles_ | Property name, unit number, address (Street number, Street Name, City, State, Country, Zip), year built, dimensions (H,W, L), area (s.ft); vehicle name, VIN code (17 digits and letters), serial model name/number | | |
| _Login details_ | Username, password | | |
| _Processor or device serial number_ | Letter(s) and/or digits | | |
| _Media access control (MAC)_ | 48-bit number | | |
| _Internet Protocol (IP) address_ | 32-bit number | | |
| _Device IDs_ | Letter(s) and/or digits | | |
| _Cookies_ | Name, value, attributes (cookie's expiration, domain, and flags) | | |
# Technical Implementation Guide
## Areas of Concern
| **COMPONENT** | **CONCERN** | **SOLUTION** |
| ---| ---| --- |
| Database |
| |
| Files |
| |
| System and application logs |
| |
| Emails |
| |
| Display |
| |
| API/WebPages |
| |
| | | |
| | | |
# PII (ISO/IEC 27018:2019)
# Information Considered As PII
According to NIST, PII can be divided into [linked and linkable information](https://piwik.pro/blog/what-is-pii-personal-data/).
## Linked Information
It may include any personal details that can be used to identify an individual:
* Full name
* Date of birth
* Home address
* Telephone number
* Social security number
* Passport number
* Driver’s license number
* Credit card details
* Email address
* Owned properties, vehicles
* Login details
* Processor or device serial number
* Media access control (MAC)
* Internet Protocol (IP) address
* Device IDs
* Cookies
## **Linkable Information**
It is indirect information that on its own may not identify a person but, when combined with another piece of information, could detect, trace or locate a person:
* First or last name (if common)
* Country, state, city, zip code
* Gender
* Race
* Non-specific age (e.g., 25-35 instead of 30)
* Job position, title, and workplace
## Regulation
[ISO/IEC 27018](https://www.iso.org/obp/ui/#iso:std:iso-iec:27018:ed-2:v1:en) regulates how well the data should be protected.
# Data Privacy Framework
A Data Privacy Framework is a documented conceptual structure that can help businesses protect sensitive data like payments, personal information, and intellectual property. The framework specifies how to define sensitive data, analyze risks affecting the data, and implement security controls.
While there are established data privacy frameworks such as the **Payment Card Industry Data Security Standard (PCI DSS)**, the **ISO 27000** family of standards, and the EU **General Data Protection Regulation (GDPR)**, there are benefits to creating a custom framework for your organization.
A custom Data Protection Framework will help emphasize the most sensitive and valuable data within an organization and design controls suitable for your organizational structure, culture, regulatory requirements, and security budget.
The organization/Client should implement to following tools to achieve PII security compliance:
* **Endpoint management -** endpoint protection is a broad category that includes everything from managing device firmware and monitoring hardware activity to providing on-device security in the form of antivirus protection.
* **2FA or MFA -** 2FA and MFA are part of IAM and can help verify that a user logging in is who they say they are.
* **Encryption -** is key for working with data in motion and data at rest (e.g., data that’s being transferred via email and any PII that’s being stored securely). Find an encryption tool that also allows you to decrypt data as needed.
* **Storage -** secure storage could come in an offsite server, encrypted hard drive, or any cloud storage system that uses cloud DLP software.
### Team Security Checklist
| **CHECK** | **ITEM** |
| ---| --- |
|
| All team members had gone through security training and are familiar with General security policy |
|
| Security requirements are known for the project and documented |
|
| All project accounts are linked to work email |
|
| All stakeholders received a minimum required permissions to perform work assigned |
|
| The project team uses its own accounts that are not shared for \[development\] environments |
|
| Credentials to services are stored in a safe place and shared via special encrypted software (KeePassXC) |
|
| Sensitive data must be sent using the secure service "[SendInc](https://www.sendinc.com/)" and in separate emails |
|
| All actions in development environments are logged and stored |
|
| Project services that require MFA are defined and set up to support it |
|
| The project team is aware of You don't have access to this Doc |
|
| The team performs a review of found high-risk code (by SonarQube or using 3rd party audit service) |
|
| The code backup process is set up, and there is a copy of the code created daily at 4:00 am |
|
| Credentials to the Production environment and related services are shared with assigned stakeholders |
|
| The data breach response and disaster recovery plans are developed |
|
| DevOps follow the Amazon/Azure security recommendations and [Support Flow](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4181) |
|
| Remote access is enabled for authorized stakeholders \[through VPN, MFA\] |
# PII Security Controls
The Data Privacy Framework should define which security controls the organization needs to have in place to prevent data loss or data leak:
* **Change Management -** tracking and auditing changes to configuration on IT systems that might have security implications, such as adding/removing user accounts.
* **Data Loss Prevention -** implementing systems that can track sensitive data transferred within the organization or outside it and identify unnatural patterns that might suggest a breach.
* **Data masking -** ensuring that data is stored or transmitted with the minimal required details for the specific transaction, with other details masked or omitted.
* **Ethical walls -** implementing screening mechanisms to prevent certain departments or individuals within an organization from viewing PII that is irrelevant to their work or might create a conflict of interest.
* **Privileged user monitoring -** monitoring all privileged access to files and databases, user creation and newly granted privileges, blocking and alerting when detected suspicious activity.
* **Sensitive data access auditing -** in parallel to monitoring activities by privileged users, monitoring and auditing all access to sensitive data, blocking and alerting suspicious or anomalous activity.
* **Secure audit trail archiving -** ensuring that any activity conducted on or in relation to PII is audited and retained for 1-7 years for legal or compliance purposes and to enable forensic investigation of security incidents.
* **User rights management -** identifying excessive, inappropriate, or unused user privileges and taking corrective action, such as removing user accounts that have not been used for several months.
* **User tracking -** implementing ways of tracking user activity online and using organizational systems to identify negligent exposure of sensitive data, compromised user accounts, or malicious insiders.
The result of the checklist & PII Security Controls above produce action items.
# HIPAA Compliance
There is an evaluation standard in the Security Rule § 164.308(a)(8). It requires you to perform a periodic technical and non-technical evaluation to ensure that your security policies and procedures meet the security requirements outlined in the rule. HHS doesn’t care if the evaluation is performed internally or by an external organization - just as long as it happens.
Companies that deal with protected health information (PHI) must have a physical, network, and process security measures and follow them to ensure HIPAA Compliance.
Protected health information (PHI) is any demographic information that can be used to identify a patient or client of a HIPAA-beholden entity. Common examples of PHI include names, addresses, phone numbers, Social Security numbers, medical records, financial information, and full facial photos, to name a few.
Covered entities (anyone providing treatment, payment, and operations in healthcare) and business associates (anyone who has access to patient information and provides support in treatment, payment, or operations) must meet HIPAA Compliance. Other entities, such as subcontractors and any other related business associates, must also be in compliance.
A Covered Entity is one of the following:
| **A Health Care Provider** | **A Health Plan** | **A Health Care Clearinghouse** |
| ---| ---| --- |
| This includes providers such as:
...but only if they transmit any information in an electronic form in connection with a transaction for which HHS has adopted a standard. | This includes:
| This includes entities that process nonstandard health information they receive from another entity into a standard (i.e., standard electronic format or data content), or vice versa. |
# HIPAA Compliance
[HHS](https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html) points out that as health care providers and other entities dealing with PHI move to computerized operations, including computerized physician order entry (CPOE) systems, electronic health records (EHR), and radiology, pharmacy, and laboratory systems, HIPAA compliance is more important than ever. [Self-check document](https://drive.google.com/file/d/1jGbSfp40if0_5qy-u2W0NeZmrrKUHE7g/view?usp=sharing).
The HHS requires physical and technical safeguards for organizations hosting sensitive patient data. These physical safeguards include:
* Limited facility access and control with authorized access in place
* Policies about use and access to workstations and electronic media
* Restrictions for transferring, removing, disposing, and re-using electronic media and ePHI
Along the same lines, the technical safeguards of HIPAA require access control allowing only authorized personnel to access ePHI. Access control includes…
* Using unique user IDS, emergency access procedures, automatic log-off, and encryption and decryption
* Audit reports or tracking logs that record activity on hardware and software.
Other technical policies for HIPAA compliance need to cover integrity controls or measures to confirm that ePHI is not altered or destroyed. IT disaster recovery and offsite backup are key components that ensure that electronic media errors and failures are quickly remedied so that patient health information is recovered accurately and intact. One final technical safeguard is a network or transmission security, ensuring HIPAA-compliant hosts protect against unauthorized access to ePHI. This safeguard addresses all data transmission methods, including email, the internet, or private networks, such as a private cloud.
To help ensure HIPAA compliance, the U.S. government passed a supplemental act, The Health Information Technology for Economic and Clinical Health ([HITECH](https://digitalguardian.com/blog/what-hitech-compliance-understanding-and-meeting-hitech-requirements)) Act, which raises penalties for health organizations that violate HIPAA Privacy and Security Rules. The HITECH Act was put into place due to the development of health technology and the increased use, storage, and transmission of electronic health information.
# Requirements For HIPAA Compliance
HIPAA regulation outlines standards that all covered entities and business associates must address.
* **Self-Audits.** HIPAA requires covered entities and business associates to conduct annual audits of their organization to assess Administrative, Technical, and Physical gaps in compliance with HIPAA Privacy and Security standards. Under HIPAA, a security risk assessment is not enough to be compliant - it’s only one essential audit that HIPAA-beholden entities are required to perform in order to maintain their compliance year-over-year.
* **Remediation Plans.** Once covered entities and business associates have identified their gaps in compliance through these self-audits, they must implement remediation plans to reverse compliance violations. These remediation plans must be fully documented and include calendar dates by which gaps will be remedied.
* **Policies, Procedures, Employee Training.** Covered entities and business associates must develop Policies and Procedures corresponding to HIPAA regulatory standards outlined by the HIPAA Rules. These policies and procedures must be regularly updated to account for changes in the organization. Annual staff training on these Policies and Procedures is required, along with documented employee attestation stating that staff has read and understood the organization’s policies and procedures.
* **Documentation.** HIPAA-beholden organizations must document all efforts they take to become HIPAA compliant. This documentation is critical during a HIPAA investigation with HHS OCR to pass strict HIPAA audits.
* **Business Associate Management.** Covered entities and business associates alike must document all vendors with whom they share PHI in any way and execute Business Associate Agreements (BAA) to ensure PHI is handled securely and mitigate liability. BAAs must be reviewed annually to account for changes to organizational relationships with vendors. BAAs must be executed before any PHI can be shared.
* **Incident Management.** If a covered entity or business associate has a data breach, they must have a process to document the breach and notify patients that their data has been compromised in accordance with the HIPAA Breach Notification Rule. Specific details about the HIPAA Breach Notification Rule and explored below.
# HIPAA Rules
The HIPAA Rules were all passed in the 20+ years that have come and gone since HIPAA was first enacted in 1996.
The HIPAA Rules apply to covered entities and business associates.
Individuals, organizations, and agencies that meet the definition of a **covered entity** under HIPAA must comply with the Rules' requirements to protect the privacy and security of health information and provide individuals with certain rights with respect to their health information. If a covered entity engages a **business associate** to help it carry out its health care activities and functions, the covered entity must have a written business associate contract or other arrangements with the business associate that establishes specifically what the business associate has been engaged to do and requires the business associate to comply with the Rules’ requirements to protect the privacy and security of protected health information. In addition to these contractual obligations, business associates are directly liable for compliance with certain provisions of the HIPAA Rules.
If an entity does not meet the definition of a covered entity or business associate, it does not have to comply with the HIPAA Rules.
* **HIPAA Privacy Rule.** The HIPAA Privacy Rule sets national standards for patients’ rights to PHI. The HIPAA Privacy Rule only applies to covered entities, not business associates. Some of the standards outlined by the HIPAA Privacy Rule include patients’ rights to access PHI, health care providers’ rights to deny access to PHI, the contents of Use and Disclosure HIPAA release forms and Notices of Privacy Practices and more. The regulatory standards must be documented in the organization’s HIPAA Policies and Procedures. All employees must be trained on these Policies and Procedures annually, with documented attestation.
* **HIPAA Security Rule.** The HIPAA Security Rule sets national standards for the secure maintenance, transmission, and handling of ePHI. The HIPAA Security Rule applies to both covered entities and business associates because of the potential sharing of ePHI. The Security Rule outlines standards for the integrity and safety of ePHI, including physical, administrative, and technical safeguards that must be in place in any health care organization. Specifics of the regulation must be documented in the organization’s HIPAA Policies and Procedures. Staff must be trained on these Policies and Procedures annually, with documented attestation.
* **HIPAA Breach Notification Rule.** The HIPAA Breach Notification Rule is a set of standards that covered entities and business associates must follow in a data breach containing PHI or ePHI. The Rule lays out different requirements for breach reporting depending on the scope and size. Organizations must report all breaches, regardless of size, to HHS OCR, but the specific protocols for reporting change depending on the type of breach.
* **HIPAA Omnibus Rule.** The HIPAA Omnibus Rule is an addendum to HIPAA regulation that was enacted to apply HIPAA to business associates and covered entities. The HIPAA Omnibus Rule mandates that business associates be HIPAA compliant and outlines the rules surrounding Business Associate Agreements (BAAs). Business Associate Agreements are contracts that must be executed between a covered entity and business associate – or between two business associates–before ANY PHI or ePHI can be transferred or shared.
# HIPAA Security Rule For Software Development
# Guidelines
The HIPAA Security Rule outlines national security standards intended to protect health data created, received, maintained, or transmitted electronically.
It basically says that any company that deals with protected health information (PHI) must ensure that all the required physical, network, and process security measures are in place and followed.
There are three parts to the HIPAA Security Rule:
1. Administrative Safeguards
2. Technical Safeguards
3. Physical Safeguards
HIPAA hosting environments such as Amazon AWS or Firehost only cover physical safeguards, therefore potentially exposing you to HIPAA violations.
# HIPAA Administrative Safeguards
The administrative components are really important when implementing a HIPAA compliance program. You are required to:
1. Assign a privacy officer
2. Complete a risk assessment annually
3. Implement employee training
4. Review policies and procedures
5. Execute Business Associate Agreements (BAAs) with all partners who handle protected health information (PHI)
Companies who can help with the administrative components of a HIPAA compliance program:
* [Accountable](http://accountablehq.com/)
* [Compliance Helper](http://www.compliancehelper.com/)
* [Compliancy Group](http://compliancy-group.com/)
# HIPAA Technical Safeguards
The technical safeguard requirements for HIPAA compliance are as follows. Be sure to see our note about the distinction between required and addressable safeguards below.
ePHI has electronically protected health information. You are governed by HIPAA laws when dealing with protected health information (PHI).
* **Unique User Identification** (required) - assign a unique name and/or number for identifying and tracking user identity.
* **Emergency Access Procedure** (required) - establish (and implement as needed) procedures for obtaining necessary ePHI during an emergency.
* **Automatic Logoff** (addressable) - implement electronic procedures that terminate an electronic session after a predetermined time of inactivity.
* **Encryption and Decryption** (addressable) - implement a mechanism to encrypt and decrypt ePHI.
* **Audit Controls** (required) - implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI.
* **Mechanism to Authenticate ePHI** (addressable) - Implement electronic mechanisms to corroborate that ePHI has not been altered or destroyed in an unauthorized manner.
* **Authentication** (required) - Implement procedures to verify that a person or entity seeking access to ePHI is the one claimed.
* **Integrity Controls** (addressable) - implement security measures to ensure that electronically transmitted ePHI is not improperly modified without detection until disposed of.
* **Encryption** (addressable) - implement a mechanism to encrypt ePHI whenever deemed appropriate.
# HIPAA Physical Safeguards
The Physical Safeguards requirements for HIPAA compliance document the access control and validation of people getting to the servers where ePHI is stored. It also details the requirements for the emergency recovery requirements and re-use and disposal of media that holds ePHI.
Typically HIPAA hosting providers only cover these safeguards, not the technical safeguards. Therefore hosting your application in a HIPAA-compliant environment is not enough to make your app itself HIPAA compliant and open you up to HIPAA violation, which can reach a maximum penalty of $50,000 per violation, with an annual maximum of $1.5 million.
# COPPA Compliance
The official up-to-date information is available on the [Federal Trade Commission website](https://www.ftc.gov/business-guidance/resources/childrens-online-privacy-protection-rule-six-step-compliance-plan-your-business).
# Six-Step Compliance Plan
Follow the step-by-step plan for determining if your company is covered by COPPA — and what to do to comply with the Rule.
## Step 1: Determine If Your Company Is A Website Or Online Service That Collects Personal Information From Kids Under 13
COPPA doesn’t apply to everyone operating a website or other online service. Put simply, and COPPA applies to operators of websites and online services that collect personal information from kids under 13.
## Step 2: Post A Privacy Policy That Complies With COPPA
It must clearly and comprehensively describe how personal information collected online from kids under 13 is handled. The notice must describe not only _your_ practices but also the practices of any others collecting personal information on your site or service — for example, plug-ins or ad networks.
## Step 3: Notify Parents Directly About Your Information Practices Before Collecting Personal Information From Their Kids
COPPA requires that you give parents “direct notice” of your information practices before collecting information from their kids. In addition, if you make a material change to the practices parents previously agreed to, you have to send an updated direct notice.
## Step 4: Get Parents’ Verifiable Consent Before Collecting Personal Information from Their Kids.
Before collecting, using, or disclosing personal information from a child, you must get their parent’s verifiable consent. COPPA leaves it up to you how you get that, but it’s important to choose a method reasonably designed in light of available technology to ensure that the person giving the consent is the child’s parent. If you have actual knowledge that you’re collecting personal information from a site or service that is directed to children, you may get consent directly or through the child-directed site or service.
## Step 5: Honor Parents’ Ongoing Rights With Respect To Personal Information Collected From Their Kids
Even if parents have agreed that you may collect information from their kids, parents have ongoing rights - and you have continuing obligations.
## Step 6: Implement Reasonable Procedures To Protect The Security Of Kids’ Personal Information.
COPPA requires you to establish and maintain reasonable procedures to protect the confidentiality, security, and integrity of personal information collected from children. Minimize what you collect in the first place. Take reasonable steps to release personal information only to service providers and third parties capable of maintaining its confidentiality, security, and integrity. Get assurances they’ll live up to those responsibilities. Hold on to personal information only as long as is reasonably necessary for the purpose for which it was collected. Securely dispose of it once you no longer have a legitimate reason for retaining it.
The COPPA requires the Commission to act on a request for "safe harbor" treatment within 180 days of the filing of the request, and after the proposed guidelines have been subject to notice and comment. Section 312.10 of the final Rule sets out the criteria for approval of guidelines and the materials that must be submitted as part of a safe harbor application.
# Limited Exceptions to COPPA’s Verifiable Parental Consent Requirement Chart
| **Reason you may collect information without parental consent** | **The kind of information you may collect** | **Other limits on how you may use the information** | **If you collect information under this exception, what you must tell parents in your direct notice** |
| ---| ---| ---| --- |
| To get verifiable parental consent | Сhild’s and parent’s name and online contact information | You must delete their contact information if you don’t get consent within a reasonable time. | You must:
|
| To give voluntary notice to a parent about their child’s participation on a site or service that doesn’t collect personal information | Parent’s online contact information | | You must:
|
| To respond directly to a child’s specific one-time request (for example, if the child wants to enter a contest) | Сhild’s online contact information | You can’t use the information to contact the child again and you must delete it after you respond to the request. | No direct notice is required. |
| To respond directly more than once to a child’s specific request (for example, if the child wants to receive a newsletter) | Сhild’s and parent’s online contact information | You can’t combine this information with any other information collected from the child. | You must:
|
| To protect a child’s safety | Сhild’s and parent’s name and online contact information | | You must:
|
| To protect the security or integrity of your site or service, to take precautions against liability, to respond to judicial process, or — as permitted by law — to provide information to law enforcement | Сhild’s name and online contact information | | No direct notice is required. |
| To provide support for internal operations of your site or service.
This includes:
| Persistent identifier | You can’t use the information to contact a specific person, including through behavioral advertising, to amass a profile on a specific person, or for any other purpose.
You can’t use this exception if you collect personal information other than a persistent identifier. | No direct notice is required. |
| If you have actual knowledge that a person’s information was collected through a child-directed site, but their previous registration indicates the person is 13 or over
This exception applies only if:
| Persistent identifier | You can’t use this exception if you collect information other than a persistent identifier. | No direct notice is required. |
See also the [FAQ](https://www.ftc.gov/business-guidance/resources/complying-coppa-frequently-asked-questions) to comply with COPPA.
# PCI DSS Compliance
While the PCI SSC has no legal authority to compel compliance, it is required for any business that processes credit or debit card transactions. PCI certification is also considered the best way to safeguard sensitive data and information, thereby helping businesses build long-lasting and trusting relationships with their customers.
# PCI DSS Compliance Levels
PCI certification ensures card data security at your business through a set of requirements established by the PCI SSC. These include several commonly known best practices:
* Installation of firewalls
* Encryption of data transmissions
* Use of anti-virus software
PCI compliance is divided into four levels, based on the annual number of credit or debit card transactions a business processes. The classification level determines what an enterprise needs to do to remain compliant.
| **LEVELS** | **AMOUNT** |
| ---| --- |
| **Level 1** | 6 Millions+ Transactions/Year |
| **Level 2** | 1-6 Million Transactions/Year |
| **Level 3** | 20K - 1Million Transactions/Year |
| **Level 4** | <20K Transactions/Year |
* **Level 1 -** applies to merchants processing more than six million real-world credit or debit card transactions annually. Conducted by an authorized PCI auditor, they must undergo an internal audit once a year. In addition, once a quarter, they must submit to a PCI scan by an [Approved Scanning Vendor (ASV)](https://www.pcisecuritystandards.org/assessors_and_solutions/approved_scanning_vendors).
* **Level 2 -** applies to merchants processing between one and six million real-world credit or debit card transactions annually. They must complete an assessment using a [Self-Assessment Questionnaire (SAQ)](https://drive.google.com/file/d/13U0gsAG4TZ0cqZZ2Xk7VXAFWQR6MU8Xq/view?usp=sharing) once a year. Additionally, a quarterly PCI scan may be required.
* **Level 3 -** applies to merchants processing between 20,000 and one million e-commerce transactions annually. They must complete a yearly assessment using the relevant SAQ. A quarterly PCI scan may also be required.
* **Level 4 -** applies to merchants processing fewer than 20,000 e-commerce transactions annually or those that process up to one million real-world transactions. A yearly assessment using the relevant SAQ must be completed, and a quarterly PCI scan may be required.
# PCI DSS requirements
The PCI SSC has outlined 12 requirements for handling cardholder data and maintaining a secure network. Distributed between six broader goals, all are necessary for an enterprise to become compliant.
## **Secure network**
* A firewall configuration must be installed and maintained
* System passwords must be original (not vendor-supplied)
## **Secure cardholder data**
* Stored cardholder data must be protected
* Transmissions of cardholder data across public networks must be encrypted
## **Vulnerability management**
* Anti-virus software must be used and regularly updated
* Secure systems and applications must be developed and maintained
## **Access control**
* Cardholder data access must be restricted to a business need-to-know basis
* Every person with computer access must be assigned a unique ID
* Physical access to cardholder data must be restricted
## **Network monitoring and testing**
* Access to cardholder data and network resources must be tracked and monitored
* Security systems and processes must be regularly tested
## **Information security**
* A policy dealing with information security must be maintained.
Businesses can safeguard against application-layer attacks by deploying a WAF between the application and clients. The WAF inspects all incoming traffic and filters out malicious attacks.
Find more information about [PCI DSS Requirement 12 here](https://www.pcidssguide.com/pci-dss-requirement-12/).
## To be PCI compliant
1. Only process credit cards using a PCI Compliant Service Provider or PCI Approved Software.
2. Never store the card security code (the three-digit number on the back of Visa / MasterCard / Discover cards or the four-digit number on the front of American Express cards).
3. Never, ever store the magnetic track data from any card.
4. Encrypt any electronic storage of full credit and debit card numbers.
5. Keep any paper documents containing a full credit card number in a secure location (locked file drawer/safe) when not used.
6. Allow only employees with a business need to have access to credit card numbers.
7. Never share user IDs and passwords or the use of group user accounts.
8. Use strong passwords (at least 7+ alphanumeric characters) for all system access.
9. Immediately disable access for all terminated employees.
10. Secure and regularly examine all POS swipe devices for signs of tampering.
11. Secure all your business computers by installing and activating personal firewalls and anti-virus/anti-malware software and disabling all generic or default user accounts and passwords.
12. Create a security policy for your business that addresses all aspects of the PCI DSS.
For most low-volume merchants, that’s it. A quarterly scan of your systems is also required for higher volume merchants, who process more than 1 million transactions per year or more than 20,000 online transactions per year. Some services perform these scans for less than $100.
# SOC 2 Compliance
| | **SOC 1** | **SOC 2** |
| ---| ---| --- |
| **Purpose** | Helps a service organization report on internal controls which pertain to financial statements by its customers. | Helps a service organization report on internal controls that protect customer data, relevant to the five Trust Services Criteria. |
| **Control objectives** | A SOC 1 audit covers the processing and protection of customer information across business and IT processes. | A SOC 2 audit covers all combinations of the five principles. Certain service organizations, for example, deal with security and availability, while others may implement all five principles due to the nature of their operations and regulatory requirements. |
| **Audit intended for**
| The CPA of the audited organization’s managers, external auditors, user entities (customers of the audited service organization), and CPAs who audit their financial statements. | Executives, business partners, prospects, compliance supervisors, and external auditors of the audited organization. |
| **Audit used for**
| Helps user entities understand the impact of service organization controls on their financial statements. | Overseeing service organizations, supplier management plans, internal corporate governance and risk management processes, and regulatory oversight. |
Developed by the American Institute of CPAs ([AICPA](http://www.aicpa.org/InterestAreas/FRC/AssuranceAdvisoryServices/Pages/AICPASOC2Report.aspx)), SOC 2 defines criteria for managing customer data based on five "trust service principles" - security, availability, processing integrity, confidentiality, and privacy.
Unlike PCI DSS, which has very rigid requirements, SOC 2 reports are unique to each organization. In line with specific business practices, each designs its controls to comply with one or more of the trust principles.
These internal reports provide you (along with regulators, business partners, suppliers, etc.) with important information about how your service provider manages data.
There are two types of [SOC reports](https://us.aicpa.org/interestareas/frc/assuranceadvisoryservices/aicpasoc2report):
* **Type I** - a snapshot assessment of the vendor's controls at a specific time and an evaluation of how suitable they are to meet the SOC 2 trust principles going forward. As this quicker, less in-depth report doesn’t monitor the long-term success, it’s not as trusted or relied upon as Type II.
* **Type II** A more [detailed](https://us.aicpa.org/interestareas/frc/assuranceadvisoryservices/soc2additionalsubjectmatter), comprehensive, and in-depth analysis of your security systems and rules is evaluated over time (typically a year). This is the preferred report and certification of prospects. In many cases, it may be the type specifically required.
# SOC 2 Trust Principles
SOC 2 certification is issued by outside auditors. They assess how a vendor complies with one or more of the five trust principles based on the systems and processes.
## **1\. Security**
The security principle refers to the protection of system resources against unauthorized access. Access controls help prevent potential system abuse, theft or unauthorized removal of data, misuse of the software, and improper alteration or disclosure of information.
IT security tools such as network and web application firewalls (WAFs), two-factor authentication, and intrusion detection are useful in preventing security breaches that can lead to unauthorized access of systems and data.
## **2\. Availability**
The availability principle refers to the accessibility of the system, products, or services as stipulated by a contract or service level agreement (SLA). As such, the minimum acceptable performance level for system availability is set by both parties.
This principle does not address system functionality and usability but does involve security-related criteria that may affect availability. Monitoring network performance and availability, site failover, and security incident handling are critical.
## **3\. Processing integrity**
The processing integrity principle addresses whether or not a system achieves its purpose (i.e., delivers the right data at the right price at the right time). Accordingly, data processing must be complete, valid, accurate, timely, and authorized.
However, processing integrity does not necessarily imply data integrity. If data contains errors before being input into the system, detecting them is not usually the responsibility of the processing entity. Monitoring data processing, coupled with quality assurance procedures, can help ensure processing integrity.
## **4\. Confidentiality**
Data is considered confidential if access and disclosure are restricted to a specified set of persons or organizations. Examples may include data intended only for company personnel and business plans, intellectual property, internal price lists, and other types of sensitive financial information.
Encryption is an important control for protecting confidentiality during transmission. Network and application firewalls, together with rigorous access controls, can be used to safeguard information being processed or stored on computer systems.
## **5\. Privacy**
The privacy principle addresses the system’s collection, use, retention, disclosure, and disposal of personal information according to an organization’s privacy notice and criteria outlined in the AICPA’s generally accepted privacy principles (GAPP).
Personal identifiable information (PII) refers to details distinguishing an individual (e.g., name, address, Social Security number). Some personal data related to health, race, sexuality, and religion are also considered sensitive and require extra protection. Controls must be put in place to protect all PII from unauthorized access.
A SOC 2 Type II assessment is a lengthy undertaking that can cost $10,000 to $50,000 and is good for 12 months from the issue date. To achieve SOC 2 certification, one must pass an external audit and receive a SOC 2 audit report.
## Compliance Checklist
Please see the various checklist samples below:
* [Sample 1](https://drive.google.com/file/d/1fTU2zGoJzUknrCT57orSfKZqu4iK6-lx/view?usp=sharing)
* [Sample 2](https://drive.google.com/file/d/16gdYCng6DODmkrEABZcxjOslRdVctqy9/view?usp=sharing)
[SOC 2® Reporting on an Examination of Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy](https://www.aicpa.org/cpe-learning/publication/soc-2-reporting-on-an-examination-of-controls-at-a-service-organization-relevant-to-security-availability-processing-integrity-confidentiality-or-privacy)
# Sprint Planning (Guidelines)
[Ukrainian version of this guideline](https://docs.google.com/document/d/1RHZNKtIK0DNm3VEHx2z0P-ANgEdYXYGr7LeVuatmzxg/edit?usp=share_link)
A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, and well-defined users or customers. A product could be a service, physical, or something more abstract.
The whole Project scope is managed better when small chunks are planned periodically. Like the Work breakdown structure (WBS), these small chunks (epics, stories, tasks) better fit the timeframe equal to weeks or months the most. This is what we call Sprints.
Sprint Planning is iterative and timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
Sprint Planning initiates the Sprint by laying out the work for the Sprint. This resulting plan is created by the collaborative work of the entire Team.
The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal. The Team may also invite other people to attend Sprint Planning to provide advice.
# Guideline
1. Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Team may refine these items during this process, which increases understanding and confidence.
2. Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, upcoming capacity, and [**_Definition of Done_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3941), the more confident they will be in their Sprint planning and [**forecasting**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3881).
3. For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.
4. Any task-tracking system can be used to visualize planning activities. It encompasses:
1. resources evaluation
1. people availability (vacations, sicknesses, onboarding)
2. tools availability (tools needed to reach the Sprint goal)
3. capacity for the Sprint
2. priorities revision
3. task estimation
4. people assignment
5. discussion and possibly:
1. resolving dependencies
2. ambiguous requirements
3. saying "No" to items that cannot be completed
# Sprint Review (Guidelines)
[Ukrainian version of this guideline](https://docs.google.com/document/d/1ZZx1vbcV03mD7-dR2JSpIKaLge250BhE6f9hLnCmwnw/edit?usp=share_link)
Sprint demo is conducted on the last day of Sprint by default as part of Sprint review. It represents the visual part of deliverables done during the Sprint.
Principles and the process are defined in each project based on the [**_Feedback_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3901?block=block-5eccbaa7-c788-4f59-8380-a99c7e3efcb5) guidelines.
Find the [**Template**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5401) [**here**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5401)
TEXT in **_bold_** **_italic orange_** **_(including links in_** **_light blue_****_)_** is meant to be adopted by each project.
The updates to increment are demonstrated by assigned people. Usually, these people present are Project Managers, Tech Leads, and rarely others.
# Guideline
1. Planned deliverable items are to be added to the list during the Sprint just as the [**_Definition_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3941) [**_of Done_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3941) is applicable
2. Items are shown in order and within the timebox of the demo \[meeting\], which can be up to **_1.5 hours_**. If there are more things to review, it is recommended to have two meetings with a short break in between
3. The list of items is prioritized, and main features and enhancements come first (Sprint priorities are set during the [**_Planning_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4001) meeting)
4. They should include a name, a short description, test data (e.g., credentials), and noted feedback.
5. The more technical part has to come last, and maybe not all participants have to be involved
6. Deliverables like completed tech design, investigation, or report should also be mentioned, but they are not a subject of obligatory demonstration
7. After each item, there should be a Q&A session for up to **_10 minutes_**. Stakeholders should be able to ask questions related only to the particular item
8. The meeting recording must be stored as part of a project for future reference.
1. separate end-user and technical parts
9. The samples of test data must be prepared beforehand
# **Rules**
* Attendees include the Scrum teams and key stakeholders invited by the Product Owner;
* The meeting facilitator explains what Product Backlog items have been "Done" and what has not been "Done";
* The Development Teams may mention what went well during the Sprint, what problems it ran into, and how those problems were solved;
* The Development Team demonstrates the work that it has "Done" and answers questions about the Increment;
* The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed);
* The entire group collaborates on what to do next so that the Sprint Review provides valuable input to subsequent Sprint Planning;
* Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,
* Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.
# Sprint Retrospective (Guidelines)
[Ukrainian version of this guideline](https://docs.google.com/document/d/18gh-HOpn-Z3Se-1pdNui4ekbnswdBFlfZKDQl5nB9Cw/edit?usp=share_link)
"The purpose of the \[Sprint\] Retrospective is to plan ways to increase quality and effectiveness. The \[Scrum\] Team inspects how the last iteration went with regard to individuals, interactions, processes, tools, and their Definition of Done. The \[Sprint\] Retrospective concludes the iteration."
Find the [**Template here**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4021)
# Guideline
Retrospective meetings are timeboxed to a maximum of three hours for one-month iterations. For shorter Sprints/iterations, the event is usually shorter.
Regular agile retrospectives are a cheap, fast, and effective way for project teams to improve continuously. They:
* Provide dedicated time to reflect, analyze, and decide on how to do things better;
* Provide a forum to celebrate success and progress;
* Improve team communications and create an opportunity to “clear the air”;
* Address issues regularly, eliminating problems sooner rather than later;
* Bring everyone up to speed on current challenges and goals;
* Empower teams to solve problems, develop solutions, and own their decisions;
* Provide an opportunity to reach a consensus on future actions moving forward;
* Offer a great opportunity for team building and energizing the team;
* The agile retrospective is best known as a tool for agile software development teams (including scrum, and extreme programming). However, it is broadly applicable to any project.
# STAR Retrospective
Each \[Scrum\] team may use a board to visualize items that need to be worked on.
Besides that, it is recommended to formally keep track of such records in a structured way.
# Tips For Effective Retrospectives
* Carefully select participants to provide expert knowledge but also a fresh perspective;
* Use technology to involve critical people in different locations rather than miss their contribution;
* Minimize groupthink by brainstorming ideas individually and then combining issues to get the overall picture;
* Be specific rather than broad when defining ideas;
* Use quantitative data where possible to focus on the crux of the issue;
* Provide adequate time in the session to rank and prioritize ideas;
* Communicate outcomes to stakeholders and regularly update progress on actions;
* Add rules and agreements to [Agile or Team charter](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3841).
# Scaled Scrum Team Retrospective
### **Because there are common scaling dysfunctions, every Retrospective should address the following questions**
* Has the Team met the Sprint Goal? If not, why not?
* Was any work left undone? Did the Team generate technical debt?
* Were all artifacts, particularly code, frequently (ideally, continuously) and successfully integrated?
* Was the software successfully built, tested, and deployed often enough to prevent the overwhelming accumulation of unresolved dependencies?
### **When issues are discovered, the representatives need to ask**
* Why did this happen?
* How can the issue be fixed?
* How can recurrence be prevented?
After the Retrospective meeting where Integration Team participates, it is important to define the action items to work on within all Scrum teams. The Integration Team has to keep track of such items and may use a table tool to keep working on items of improvement.
# Stakeholder Management (Guidelines)
[Ukrainian version of this guideline](https://docs.google.com/document/d/1wKV2Cc3-h1eBXwmptDcmQDDiHQ-_FA6CWTVyqmgMZ2I/edit?usp=share_link)
# Stakeholder Register
Stakeholders can be individuals, groups, or organizations that may affect, be affected by, or perceive themselves to be affected by a decision, activity, or outcome of a portfolio, program, or project. Stakeholders also directly or indirectly influence a project, its performance, or its outcome in either a positive or negative way.
Find the **Templates** **for** [**large**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5441) **and** [**small**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7482) **projects, respectively.**
All the information about stakeholders is compiled in the register (templates). The register serves monitoring and control purposes. **NO PERSONAL INFO SHALL BE USED OR SHARED OUTSIDE THE PROJECT**
# Guideline
While having relevant technical skills is an important aspect of successful projects, having the interpersonal and leadership skills to work effectively with stakeholders is just as important factor.
Stakeholder engagement includes implementing various strategies and actions to promote the productive involvement of each and everyone on a project. Stakeholder engagement activities start before the project starts and continue throughout the journey to deliver value for the end users.
Effective and efficient engagement and communication include determining how, when, how often, and under what circumstances stakeholders want to be and should be engaged.
Thus, communication is a key part of engagement; however, engagement delves deeper to include awareness of the ideas of others, assimilation of other perspectives, and collective shaping of a shared solution. Engagement includes building and maintaining solid relationships through frequent, two-way communication. It encourages collaboration through interactive meetings, face-to-face meetings, informal dialogue, and knowledge-sharing activities.
According to the PMBOK 7th Ed., the rights steps to take when working with stakeholders are:
* Identify their roles
* Understand and analyze their needs, values, expectations, power, and degree of influence
* Prioritize the work based on stakeholder power, interest, and engagement level
* Engage with them to properly manage expectations, elicit requirements, satisfy reasonable requests
* Monitor satisfaction by questioning stakeholders, sending surveys, receive feedback during any kind of communication.
# The Flow
1. Define each stakeholder in the project and his expectations
2. Record the aforementioned data in the table depending on the source of documentation
1. Confluence pages
2. Google sheets
3. MS Office documents
3. Make sure the "**Impact**" has been clearly defined, and specific details are stated.
1. Dates/deadlines
2. Unambiguous terms, set of responsibilities
3. Hyperlinks
4. Revisit the stakeholder register once per Sprint/month to keep it up-to-date
5. It is recommended to include the communication plan details or link to a separate document (The communication plan must also include a flow in case of emergency)
6. Roles on the DevCom's side are, but not limited to:
1. Account Manager
2. Project Manager
3. Project Administrator
4. Tech Lead
5. Developer
6. QA Lead
7. QA
8. DevOps
9. UI/UX Designer
10. Tech Writer
# Team Stages (Guidelines)
[Ukrainian version of this guideline](https://docs.google.com/document/d/1Loxc1Y85gH4mdCMiiTVIprS6vLgx7Yz7Gfqm2NdM_WA/edit?usp=share_link)
Teams go through stages of development. The most commonly used framework for a team's stages of development was developed in the mid-1960s by Bruce W. Tuckman. Although many authors have written variations and enhancements to Tuckman's work, his descriptions of **Forming**, **Storming**, **Norming,** and **Performing** provide a useful framework for looking at your own team. Nowadays, we can also add the **Adjourning** stage.
Find the [**Template here**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-9241)
# Stages
## Team Stages
## ↓
#### Forming → Storming → Norming → Performing → Adjourning
## Stage 1: Forming
### General
During the Forming stage of team development, team members are usually excited to be part of the team and eager about the work ahead. Members often have high positive expectations for the team experience. At the same time, they may also feel some anxiety.
### Behavior
Behaviors observed during the Forming stage may include lots of questions from team members, reflecting both their excitement about the new team and the uncertainty or anxiety they might be feeling about their place on the team.
### Target
The principal work for the team during the Forming stage is to create a team with clear structure, goals, direction, and roles so that members begin to build trust. A good orientation/kick-off process can help to ground the members in terms of the team's mission and goals, and can establish team expectations about both the team's product and, more importantly, the team's process.
## Stage 2: Storming
### General
As the team begins to move towards its goals, members discover that the team can't live up to all of their early excitement and expectations. Their focus may shift from the tasks at hand to feelings of frustration or anger with the team's progress or process. Members may express concerns about being unable to meet the team's goals. During the Storming stage, members are trying to see how the team will respond to differences and how it will handle conflict.
### **Behavior**
Behaviors during the Storming stage may be less polite than during the Forming stage, with frustration or disagreements about goals, expectations, roles, and responsibilities being openly expressed. Members may express frustration about constraints that slow their individual or the team's progress; this frustration might be directed towards other members of the team, the team leadership, or the team's sponsor.
### Target
Team tasks during the Storming stage of development call for the team to refocus on its goals, perhaps breaking larger goals down into smaller, achievable steps. The team may need to develop both task-related skills and group process and conflict management skills. A redefinition of the team's goals, roles, and tasks can help team members past the frustration or confusion they experience.
## Stage 3: Norming
### General
During the Norming stage of team development, team members begin to resolve the discrepancy they felt between their individual expectations and the reality of the team's experience. If the team is successful in setting more flexible and inclusive norms and expectations, members should experience an increased sense of comfort in expressing their "real" ideas and feelings. Team members feel an increasing acceptance of others on the team, recognizing that the variety of opinions and experiences makes the team stronger and its product richer. Constructive criticism is both possible and welcomed.
### **Behavior**
Behaviors during the Norming stage may include members making a conscious effort to resolve problems and achieve group harmony. There might be more frequent and more meaningful communication among team members, and an increased willingness to share ideas or ask teammates for help. Team members refocus on established team ground rules and practices and return their focus to the team's tasks.
### Target
During the Norming stage, members shift their energy to the team's goals and show an increase in productivity, in both individual and collective work. The team may find that this is an appropriate time for an evaluation of team processes and productivity.
## Stage 4: Performing
### General
In the Performing stage of team development, members feel satisfaction in the team's progress. They share insights into personal and group processes and are aware of their own (and each other's) strengths and weaknesses. Members feel attached to the team as something "greater than the sum of its parts" and feel satisfaction in the team's effectiveness.
### **Behavior**
Team members are able to prevent or solve problems in the team's process or in the team's progress. A "can do" attitude is visible as there are offers to assist one another. Roles on the team may have become more fluid, with members taking on various roles and responsibilities as needed.
### Target
In the Performing stage, the team makes significant progress toward its goals. Commitment to the team's mission is high and the competence of team members is also high. Team members should continue to deepen their knowledge and skills, including working to continuously improve team development. Accomplishments in team processes or progress are measured and celebrated.
## Stage 5: Adjourning
Some teams do come to an end, when their work is completed or when the organization’s needs change. While not part of Tuckman’s original model, it is important for any team to pay attention to the end or termination process.
### General
Team members may feel a variety of concerns about the team’s impending dissolution. They may be feeling some anxiety because of uncertainty about their individual role or future responsibilities. They may feel sadness or a sense of loss about the changes coming to their team relationships. And at the same time, team members may feel a sense of deep satisfaction at the accomplishments of the team. Individual members might feel all of these things at the same time or may cycle through feelings of loss followed by feelings of satisfaction.
### **Behavior**
During the Ending Stage, some team members may become less focused on the team's tasks and their productivity may drop. Alternatively, some team members may find focussing on the task at hand is an effective response to their sadness or sense of loss.
### Target
The team needs to acknowledge the upcoming transition and the variety of ways that individuals and the team may be feeling about the team’s impending dissolution. During this stage, the team should focus on three tasks:
1. Completion of any deliverables and closure on any remaining teamwork.
2. Evaluation of the team’s process and product, with a particular focus on identifying "lessons learned" and passing these on to the Client, Devcom's departments for future teams to use.
3. Creating a closing celebration that acknowledges the contributions of individuals and the accomplishments of the team and that formally ends this particular team's existence.
# 1-To-1 Meeting
[Ukrainian version of this guideline](https://docs.google.com/document/d/11qo_3JOHifAb4X6qolIxPnyoQvpIYbzSo0wHvES_Y40/edit?usp=share_link)
A 1-to-1 meeting is a regular check-in between two people in DevCom – typically a manager and an employee. It is used to give feedback, keep each other in the loop, resolve issues, and help the participants grow in their roles. The key point is to "allow the employee to guide the conversation in the way they want".
# Guideline
The free-form, employee-focused nature that goes beyond status updates makes the 1-to-1 special. It’s often considered the most important meeting because it lays the foundation for a trusting and productive work relationship. A [good meeting](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3921) could have the following characteristics:
* It is set up on a regular basis
* A manager is prepared (has an agenda, talking points, and writes a summary)
* A manager is a good listener
* All participants are open-minded and ready to share
* The dedicated time usually does not exceed 30m
* Manager/employee takes notes to follow up.
Face-to-face conversations offer the richest form of communication. So whenever possible, meet in person. If there is no chance of making it in person, rather than canceling the meeting, move to the next-richest medium: video call.
Whether it is somewhere in the office, on the walk, café, pick a place where all feel comfortable speaking openly.
One must consider 1-to-1 meetings as a powerful tool to nurture people rather than an obligation to follow one of hundred processes in the company.
## Typical Items For Agenda
The conversation shall be in free form to make it productive instead of the interview-like process. What can be discussed during this meeting:
* Work habits and employee performance
* PDP progress
* Team collaboration
* Levels of engagement
* Short & long-term performance goals
* Professional development goals and plan
* Manager improvement
# Benefits
* Develop trustful relationships between a manager/supervisor and an employee
* Track employee’s progress and set goals
* Prevent future problems
* Develop manager’s coaching skills
* Get employee engaged
* Employees get more productive
# Samples Of Questions
## Regular Check-In
Develop a trusting relationship, celebrate wins, and resolve issues early on.
* How are you doing? How did the past week/month go?
* What would you like to talk about today?
* What are you proud of? Is anything blocking you?
* Do you need any support? How can I help you?
* Anything else you’d like to talk about today?
## First 1-to-1 With a New Team Member
Lay the groundwork for a trusting relationship and worthwhile 1-to-1s.
* Tell me about yourself – what attracted you to this role?
* What are your aspirations – professionally and personally?
* What gives you energy, and what drains it?
* What’s your role, and what would you expect from me?
* Let’s talk about our team and how we work together.
* Let’s talk about why and how we’ll do 1-to-1 meetings.
* Anything else you’d like to talk about today?
## Another Level Meeting
Bridge the gap between hierarchy levels and get more insights into your organization.
* What are you proud of?
* What ideas do you have for your team and the company?
* How do you feel about the vision and priorities of our company?
* What can your manager do better to support you in your role?
* Is anything blocking you?
## Goal-setting
Make objective setting an informed and collaborative exercise.
* Let’s quickly recap why and how we set OKRs/PDP goals.
* How did previous objectives go?
* Let’s look at the company and team priorities.
* Let’s discuss current objectives and personal development goals.
* Let’s agree on the next steps.
## Employee Growth
Help individuals reflect and identify growth areas.
* Based on the feedback you have received lately, are there areas you would like to develop further?
* What next steps could you be taking toward those goals?
* What part of your job are you enjoying the most? What’s inspiring, motivating, and energizing?
* What part of your job are you enjoying the least? What is frustrating or boring to you? What is the one task you would love to stop doing, if possible?
* Where would you like to be in 2 years from now?
## Performance & PDP
Bring a performance review to a good conclusion and share learnings.
* How do you feel after this performance review?
* What did you think while reviewing my feedback and the feedback you got from your peers?
* Is there anything you need clarification about?
* Was anything surprising?
* What’s your main takeaway from this review?
## Understand and overcome performance issues
* Are you clear on what is expected of you? Do you think those expectations are realistic?
* Do you realize how your role fits into the bigger picture/why your work is important?
* Do you receive enough feedback? If not, why do you think you don’t receive it? How could we ensure you get more feedback?
* Do you feel comfortable asking for support when needed?
* What got in the way of you having more impact? (e.g., internal processes, time management issues, lack of resources or information)
* What are the action items and/or objectives we can agree on?
# Untitled
# TEMPLATES
# Agile Charter (Template)
[Ukrainian version of this guideline](https://docs.google.com/document/d/1PS2UdTr-mqDH-O3KDALGRsYWTHfp_WGqk-gbiiHudRU/edit?usp=share_link)
In Agile project management, the Team Charter can be thought of as the foundation upon which all of the team’s work, rules, tools, and behaviors are built. One of the reasons for this is Agile’s emphasis on **people instead of processes**.
Unlike traditional project management, where a charter defines the project scope and success criteria, often pre-determined by senior management/sponsors, an Agile Team Charter is built and agreed upon by the project team exclusively.
TEXT in **_bold_** **_italic orange (_****_including links in_** **_light blue_****_)_** is meant to be adopted by each project.
# Project Ground Rules
## **Rules of Behavior**
1. All team members will treat each other with respect at all times.
2. Constructive feedback is a valuable part of our success, so we will not take offense and all team members will ensure all feedback is provided in a constructive manner.
3. Open communication among the team is always welcomed and valued.
4. We will recognize and celebrate all individual and team accomplishments.
5. All personal stuff is left aside prior to beginning any of our meetings or discussions to keep a better focus.
6. We will accept responsibility and be accountable for our actions.
7. We will give consideration to whoever is speaking and avoid sidebars or speaking over one another.
8. We will work collaboratively when possible and use a consensus approach when making team decisions.
9. **_Current teams_** are the fundamental team composition to achieve the result possible.
10. All team members have to plan the **_Absence (vacation & sick Leaves)_** in advance (at least a month) for a better planning process.
11. We understand that documentation must be prepared and attached to tasks where applicable.
12. The Definition of Done (DOD) is applicable to **_Sandbox_** and **_Production_** environments.
13. After major deployments (global updates or big Epics), we dedicate **_20%_** of the QA representatives' time to regression testing.
14. We do not assign complex tasks to newcomers and plan **0** story points as per their planned capacity.
15. **_Agile Velocity Chart Gadget_** will help us to track velocity and plan scope for our _team(s)_ as well.
16. We agree to collaborate to start the task development with clear description and acceptance criteria only.
17. We want to reduce the tech debt each Sprint.
18. We want to report time after some work is done with subsequent comments on a daily basis.
19. Each team member executes only 2 tasks at once.
## **Communications**
1. Our communication is based on the ceremonies of the **_SCRUM/Kanban/XP_** framework.
2. We will hold regular daily meetings at **_11:00 AM (UKR local time)_** each workday.
3. Nexus Integration Team (NIT) Sprint planning starts after the NIT meeting in scaled Scrum. We agree the Sprint duration is **2** weeks.
4. Daily meetings for Scrum teams are held individually and agreed upon internally within each Team but are timeboxed to **15** min.
5. We will make every effort to attend all scheduled meetings online or offline (exceptions being scheduled and/or sick leaves are added to the calendar).
6. We will update our tasks on the Scrum board each workday as they move through the **_Tasks flow in the Jira_** tool.
7. Daily updates after the **_internal_** meeting will be sent out before **_8:30 AM EST_** in the **_Slack_** channel.
8. The daily sync is scheduled at **_8:30 AM EST_** to discuss the important questions based on the agenda or questionable items from daily updates. We understand and invite only those representatives who can contribute.
9. If a meeting must be canceled or additional meetings are required, the organizer will send out notifications as early as possible.
10. Accept meeting invites if you are planning to join or reject with a note and valid reason.
11. The suggestions on how to hold meetings effectively are well described in [**_Meetings Flow_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3921)**_._**
12. Refinement meetings are held each **_Tuesday_** and **_Thursday_** by default.
13. Retrospective follows the Sprint review _(_**_8:30 AM EST_**) the same day.
14. All team members are expected to be on time for all meetings.
15. We will use the [**_Feedback_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3901) loop to maintain the communication transparent and up-to-date.
16. To find information about key stakeholders, please visit the [**_Stakeholder Management_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3721) register.
17. Periodically (**_monthly_**) review the test accounts, credentials to services, access to 3rd parties accounts, and update documentation.
* * *
## **Processes**
| **POINT** | **DESCRIPTION** |
| ---| --- |
| **Tasks Life Cycle** | [Tasks flow](https://lucid.app/lucidchart/0f53aa95-5f95-4e44-a323-97e592d0e9ee/view?invitationId=inv_4968c551-ab46-49f9-8165-ce6f8c3b5454&page=G_TntI~ut8as#) describes the life cycle of each task, starting with the documentation level, and provides tips on how to overcome the pitfalls at every stage. It is already adopted the scaled scrum approach. |
| **Design-first Approach** | We want to inspect and perform the tech design before task execution to foresee the potential dependencies. |
| **Completed Features** | Tasks and features are considered as done when they correspond to the [Definition of Done](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3941) (DOD) regardless of the Sprint. |
| **QA** |
_Unit Testing is injected as part of Sprint's planning decision by the Tech Lead._
QA Strategy & Practices
|
| **Priority Change** | Swapping tasks between the current Sprint backlog and Product backlog is available only if no major dependencies exist and tasks size are equal. |
| **Product Owner Requirements Refinement** | PO keeps the ideas and partially confirmed statements as part of the [Product Development](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3981) log. |
| **Requirements Refinement** | The initial [Product Requirements](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3981) go through the clarification process and are stored within the **_Confluence space_**. |
| **Sprint Planning** | Each Sprint planning is based on the [Forecasted pre-planned](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3881) tasks. |
| **Sprint Estimation** | Tasks must have **_8_** or fewer story points when planning the sprint and doing [Estimates in Story points](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4121). One may use the [Velocity Range Calculator](https://www.mountaingoatsoftware.com/tools/velocity-range-calculator). |
| **Retrospective meeting** | Scaled team [Retrospectives](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4021) are the source to inform about the insights and are predecessors for individual teams' [R](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4021)[etrospective meetings](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4021). |
| **Knowledge Sharing** | The [Knowledge Sharing](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3961) should take place at least once per month in any form. Cross-team feature development is an essential part of knowledge sharing. |
| **Product Support** | To process the requests from end-users, we keep up with the [Support](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4161) [flow](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4161). Support activities are planned separately from regular development with dedicated up to **_15%_** of Sprint time. |
| **DevOps Support** | In case the project is affected by the negative impact, we have a guideline of [DevOps Support Flow](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4181) to follow. |
| **Releases** | Small releases are most desirable. Large Epics are presented through iterative and incremental cycles firstly on **_Sandbox_**. |
| **System Monitoring** |
_Kibana, Zabbix, AWS_
|
| **Environments Uptime** | **_All environments but Production are scheduled to be turned off on weekends and during off business hours._** |
# Change Management Flow In Production
Copy the template below the Guidelines to describe the implementation plan for every new Change Management (CM) that imposes major changes
TEXT in **_bold_** **_italic orange (_****_including links in_** **_light blue_****_)_** is meant to be adopted by each project.
# Guideline
## Planned Change Management
CM must be executed according to the following rules:
1. The task title: “CM: **_1_** (**_10-15-2021_**) **_CM\_NAME_**”
2. CM must be approved and merged
1. The major release must be approved and merged on **_Tuesday_** the latest
3. Review with Product Owner or other role representing users and amend if needed
1. Review the major release with PO and amend if needed on **_Wednesday_**
4. Start updating the Production environment no later than **_4:00 AM EST_** (**_11:00 AM local time_**) the **_next day_**
5. Finish the update no later than **_6:00 AM EST_** (**_1:00 PM local time_**)
6. Do the Regression Testing and record discrepancies if such are found.
## Unplanned Change Management
The **unplanned** CMs may take longer, be out of working hours, require more effort to implement changes, or even be urgent regardless of the time. Nevertheless, the CM-lead takes the leadership and conducts it according to the plan.
For a CM that has to be executed after DevCom's business hours:
1. The CM-lead has to make sure that people involved have proper tools, access, and the ability to implement it
2. Urgent work (e.g., hotfix, bug correction, system reboot) is being executed the same day it was reported unless other is stated
3. The DevOps team, usually the main implementer, has to be notified ahead (up to 2 days) about upcoming work and be available to execute the CM after **_12:00 PM_** **_EST (_****_07:00 PM_** **_local time)_** if necessary.
# The Process
A developer who conducts the Change management process is considered to be a CM-lead and has to drive the process from the initiation to the implementation stage.
In the task tracking system, it is recommended to have a separate type of task to track CMs.
One must use special fields are filled in when the CM is created by either the CM-lead or initiator
* **CM-Status** (_updates depending on the execution flow_)
* New
* Submitted
* Approved
* Started
* Monitoring
* Failed
* Success
* **CM-Change Type** (_choose what type of CM it is: fix, configuration, system reboot, etc._)
* Data Fix (2)
* App Hot Fix (20)
* App Config (5)
* Infrastructure Config (5)
* Infrastructure Design (25)
* App Deployment (20)
* Reboot (10)
* **CM-Change Plan** (_is it a planned change or not?_)
* Emergency (50)
* Unplanned (10)
* Planned (0)
* **CM-Implementation Plan** (_describe the step-by-step implementation. Provide enough details so that someone else can do it_)
* **CM-Possibility of Full Rollback** (_is it possible to revert changes completely?_)
* Yes (0)
* No (50)
* Partial (25)
* **CM-Rollback Plan** (_step-by-step rollback plan to return the system to the previous state before the changes were made_)
* **CM-Change Scope** (_global change (or specifically for a tenant if it is a multi-tenant application)_)
* Global (20)
* **_Client_** **\-** **_ABC_** **(****_10_****)**
* **_Client_** **\-** **_XYZ_** **(****_5_****)**
* **CM-Blast** Radius (_what is the impact if it fails_)
* **CM-Blast Radius Notes**
* **CM-Change Window** (_CM execution time_)
* **_Outside of the main window (10)_**
* **_Every Thursday: 4-6 AM EST_**
* **_Every Saturday: 4-6 AM EST_**
* **_Every Sunday: 4-6 AM EST_**
* **_Once per month: 1st weekend 4-10 AM EST_**
* **CM-Change Date** (_specify the date and time for the start of the change_)
* **CM-Primary Implementer** (a _responsible person for making Changes to the Production environment_)
* **CM-Outage Time** (_anticipated outage time (Short <2min, Long >2min_))
* None (0)
* Some Sessions Lost (0)
* All Sessions Lost (5)
* Minor Component Short (10)
* Major Component Short (20)
* Minor Component Long (20)
* Major Component Long (50)
* Unknown (50)
* **CM-Outage Duration** (min) (u_se decimals for seconds (e.g. 15sec=0.25m_))
* **CM-Test plan/method/result** (_describe the method used to test this change_)
* **CM-Tested in Environments** (_environments it was tested before submission. Pick min score_)
* Devcom (10)
* **_SandBox (0)_**
* Production (30)
* None (30)
* **CM-Validation and Monitoring** (_quick validation steps post update. Long term monitoring steps, log watching_)
* **CM-Risk Score** (s_um of risk factors (numbers in brackets next to each option)_)
* **CM-Risk Level** (_risk exposure of this change; is used with CM-Blast Radius. E.g., High - change database structure, deploy changes to AWS Firewall/VPC, upgrade Windows; Extreme - new major release_)
* Low
* Medium
* High
* Extreme
* **CM-Risk Notes** (_describe the reason for the risk level_)
* **CM-Contingency Plan** (_when a rollback is partially possible, not possible at all, or rollback failure occurs, then provide a plan to restore the system to a previous state (if available)_)
* **CM-Quality Rating** (_the rating is set by the CM Coordinator_)
* 1
* 2
* 3
* 4
* 5
* **CM-Completion Result** (_S - success, F - Failed_)
* Success (S)
* Success with HotFix (S)
* Rolled back (F)
* Failed to roll back (F)
* Contingency Plan executed (F)
* Never started (F)
* **CM-Documentation upgrade** (_the documentation is required to be updated during or after the implementation of CM_)
* No
* Yes
# Definition of Done Template
Please check the [**General Guidelines**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5341) for more information
TEXT in **_bold_** **_italic orange (_****_including links in_** **_light blue_****_)_** is meant to be adopted by each project.
# Guideline
1. **_Write unit tests for each class to cover all valuable functionality that has been added and defined._**
2. The code for a certain task is completed. Features required by a customer and/or Product Owner support acceptance criteria from a technical perspective.
3. Re-read your code and remove useless commented code.
4. Add “**TO DO**:” mark the code above to be changed or refactored and describe in the comment what else has to be done.
5. Use tools (**_ReSharper, SonarQube_**) to review and correct all major errors and warnings, including security (bugs, warnings, errors).
6. **_Run unit tests that were passed before introducing new changes. Troubleshoot the issues if something has failed._**
7. **_Run all unit tests to be sure everything is still working._**
8. Smoke tests pass by the QA team.
9. Perform functional, integration, and regression testing (on-demand or when required) according to acceptance criteria and quality requirements based on [**_QA Strategy & practices doc_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4201).
10. A task/user story/epic is merged with the main codebase (depending on the Environment).
11. After the Sprint review at the latest, all tasks must be accepted by the Product Owner (formal sign-off).
And now, a task corresponds to the “**Definition of Done**” (DoD).
Definition of Done can apply to multiple environments. Thus, one can consider **DOD** for multiple environments.
# Example Of Project Environments
# DevOps Support Flow
TEXT in **_bold_** **_italic orange (_****_including links in_** **_light blue_****_)_** is meant to be adopted by each project.
# Guideline
1. A **requester** submits a request related to one of the **General** issue types to be resolved depending on importance (e.g., **CRITICAL**) via phone, email, or any messenger.
2. If it requires **immediate** action, the **requester** may reach the responsible representatives using the contact information in the [**Stakeholder matrix**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3721) (including personal if it’s non-business hours).
1. If no one is available, one should contact Project or Account Manager.
3. If there are questions or missing info, then DevOps team member reacts accordingly to what is being asked and replies that the task is accepted via means of communication.
4. Also, a **requester** can create a ticket in the task tracking system to submit the issue/task.
5. It is recommended to set up notifications in that task tracking system, messenger, where every DevOps team member will see it.
6. After the work is completed, the DevOps representative notifies the **requester** about completion via email and/or messenger. This information can be presented in other types of PM's reports.
7. The last step is to conduct the root-cause analysis to prevent emerging such issues further on.
For **MEDIUM** or **LOW** importance, we’ll use DevCom’s local time zone to fix the next-day issue unless another is stated in the email or other means of communication.
## Action types
* **Immediate** \- ASAP fix when the issue has occurred.
* **Moderate** \- next-day fix unless it has high impact and is qualified as **Immediate**.
* **Low** \- issues can be fixed in the next two days.
# General Issue Types
| **ISSUE TYPE** | **IMPORTANCE** | **ACTION** | **NOTES** |
| ---| ---| ---| --- |
| Database Server is down | CRITICAL | **Immediate** | Investigate & fix asap |
| System Performance | CRITICAL | **Immediate** | Investigate & fix asap |
| Services server is down | CRITICAL | **Immediate** | Investigate & fix asap |
| One of the Services is down | CRITICAL / MEDIUM | **Immediate** / **Moderate** | Depends on the service |
| SSIS jobs Server is down | CRITICAL | **Immediate** | Investigate & fix asap |
| One of SSIS jobs is down | CRITICAL / MEDIUM | **Immediate** / **Moderate** | Depending on the specific job |
| API server is down | MEDIUM | **Moderate** | There is another AWS instance (high-availability) to be able to run APIs. |
| Authorization/Sign-in server | MEDIUM | **Moderate** | There is another AWS instance (high-availability) to be able to run APIs. |
| Running out of disk space | LOW | **Low** |
_25Gb_
_10Gb_
|
# Forecast Planning
The sprint forecast document helps to refine items for the next planning meeting.
Even in an agile environment, it helps to plan in advance and see the dependencies.
TEXT in **_bold_** **_italic orange (_****_including links in_** **_light blue_****_)_** is meant to be adopted by each project.
# Guideline
Sprints must have only the order numbers and dates as well as when they start and end.
## Estimates are accepted in any manner. Tasks buckets
* New Features
* Change Requests & Enhancements
* Refinement (Tech debt, security)
* Support & Bugs
The more precise estimate is given a better understanding of the forecasted volume.
If there's a single team on a Project, the column 'Team' can be omitted.
## Priorities are set as follows
* **HIGH - the task is required to be done in the planned Sprint**
* **MEDIUM - the task should be done in the planned Sprint but not as the very first item to focus on**
* **LOW - the task should be done in the planned Sprint but is the first item to swap with when other tasks with higher priorities come**
## Visuals
For better visual orientation, the cells can be colored as well.
| **Must-have item** | **Needs clarification** | **Blocked item** | **Design** |
| ---| ---| ---| --- |
**Must-have items** are items that cannot be carried over to the next Sprints.
**Needs clarification** are vague, unclear tasks where the Product Owner's input is required
**Blocked item** is usually dependent items and should be addressed as soon as possible
**Design** means the items must be groomed and designed before the coding
It is recommended to have a continuous forecasting process to enhance the Planning meetings.
| **SPRINT 1 (MM/DD-MM/DD)** | **SIZE**
**(T-Shirt, story points, hours)** | **PRIORITY** | **TEAM** | **SPRINT 2 (MM/DD-MM/DD)** | **SIZE**
**(T-Shirt, story points, hours)** | **PRIORITY**
| **TEAM**
| **SPRINT 3 (MM/DD-MM/DD)** | **SIZE**
**(T-Shirt, story points, hours)** | **PRIORITY** | **TEAM** |
| ---| ---| ---| ---| ---| ---| ---| ---| ---| ---| ---| --- |
| **NEW FEATURES** |
| **_Login window_** | **_M_** | **MEDIUM** | **_Alpha_** | | | | | | | | |
| **_Reset password_** | **_S_** | **HIGH** | **_Beta_** | | | | | | | | |
| **CHANGE REQUESTS & ENHANCEMENTS** |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| **REFINEMENT (Tech Debt, Security)** |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
| **SUPPORT & BUGS** |
| | | | | | | | | | | | |
| | | | | | | | | | | | |
# Master Service Agreement
A Master Service Agreement (MSA) is a contract made between two or more parties in which they both agree to most of the terms used to govern any future agreements or future transactions. This kind of agreement has proven itself rather useful, as it allows parties to negotiate any future deals and transactions rather quickly.
As is the case with most contractual agreements, Master Service Agreement is designed to specify generic terms, such as:
* Business ethics
* Corporate social responsibility
* Dispute resolution
* Geographic location
* Intellectual property ownership
* Family access
* Network access
* Product warranties
* Payment terms
* Venue of law
MSAs are prepared using the [Proposify](https://app.proposify.com/login) tool.
# Template
[https://docs.google.com/document/d/10enrtrytJS6XVyNR8o7Jk7Jo9BuxxdfMU2R9MIHTbKc/edit](https://docs.google.com/document/d/10enrtrytJS6XVyNR8o7Jk7Jo9BuxxdfMU2R9MIHTbKc/edit)
# Non-Disclosure Agreement
A non-disclosure agreement (NDA) is a legally binding contract establishing a confidential relationship. The parties signing the agreement agree that sensitive information they may obtain will not be made available to any others. An NDA may also be referred to as a confidentiality agreement.
* An NDA acknowledges a confidential relationship between two or more parties and protects the information they share from disclosure to outsiders.
* The NDA is standard before discussions between businesses about potential joint ventures.
* Stakeholders on both sides are often required to sign NDAs to protect confidential business information.
* An NDA may also be referred to as a confidentiality agreement.
* There are two primary non-disclosure agreements: mutual and non-mutual non-disclosure agreements.
NDAs are prepared using the [Proposify](https://app.proposify.com/login) tool.
# Template
[https://docs.google.com/document/d/1L-4gpBFHopgq22qPzIKny\_OteWFA6axf/edit](https://docs.google.com/document/d/1L-4gpBFHopgq22qPzIKny_OteWFA6axf/edit)
# Project Charter
# Guideline
A project charter is a formally issued document by the project initiator or sponsor that formally authorizes the existence of a project and empowers the project manager to apply organizational resources to project activities.
# Template
#### **PROJECT TITLE AND DESCRIPTION**
_What is the project?_
#### **PROJECT MANAGER ASSIGNED AND AUTHORITY LEVEL**
_Who is given authority to lead the project, and can he/she determine, manage, and approve changes to the budget, scope, schedule, staffing, etc.?_
#### **BUSINESS CASE**
_Why is the project being done? On what financial or other basis can we justify doing this project? The project purpose and justification)_
#### **RESOURCES PREASSIGNED**
_How many or which resources will be provided?_
#### **STAKEHOLDERS**
_Who will affect or be affected by the project \[influence the project\], as known to date?_
#### **STAKEHOLDER REQUIREMENTS AS KNOWN**
_Requirements related to both project and product scope._
#### **PRODUCT DESCRIPTION/DELIVERABLES**
_What specific product deliverables are wanted, and what will be the end result of the project?_
#### **ASSUMPTIONS**
_What is believed to be true or reliable in the situation? What do we believe to be the case but do not have proof or data for?_
#### **CONSTRAINTS**
_What factors may limit our ability to deliver? What boundaries or parameters will the project have to function within?_
#### **MEASURABLE PROJECT OBJECTIVES**
_How does the project tie into the organization’s strategic goals? What project objectives support those goals? The objectives need to be measurable and will depend on the defined priority of the project constraints._
#### **PROJECT APPROVAL REQUIREMENTS**
_What items need to be approved for the project, and who will have sign-off? What designates success? What are the business acceptance criteria?_
#### **HIGH-LEVEL PROJECT RISKS**
_Potential threats and opportunities for the project_
#### **PROJECT SPONSORS AUTHORIZING THIS PROJECT**
_People responsible for sponsoring the project_
# Project Closure Template
Please check the [**General Guidelines**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5421) for more information
TEXT in **_bold_** **_italic orange (_****_including links in_** **_light blue_****_)_** is meant to be adopted by each project.
Once the project or phase has been finalized and before the celebrations start, you need to formally round things off by moving into the closure process.
# Template
| **_PROJECT/PHASE_** **CLOSURE DOCUMENT** |
| --- |
| **START DATE**
**_MM/DD/YYYY_** | **END DATE**
**_MM/DD/YYYY_** | **ACCOUNT MANAGER**
| **PROJECT MANAGER** |
| **PROJECT GOAL DESCRIPTION**
_Short project description and purpose_ |
| **ACHIEVEMENTS & DELIVERABLES** |
| _What has been done; milestones achieved_ |
| **OWNERSHIP & RIGHTS** |
| _Who has the legal ownership, software version, sensitive information owner_ |
| **KEY DOCUMENTS** |
| _List of the documents and media files relevant to the activities that are being handed over and where they are stored_ |
| **SERVICES & CREDENTIALS** |
| _Public domains; host server details; code storage; 3rd party services; social networks, etc.; all sensitive info must be archived and encrypted_ |
| **WARRANTY & LIABILITIES** |
| _Further support, extended/prolonged agreement of dedicated team support_ |
| **CONTACTS** |
| _Key stakeholders' contact details: roles, phone number, email_ |
| **SUMMARY** |
| _General summary, next steps if known_ |
_Signing off on this document signifies that the approving client representative is satisfied with the completed deliverable listed above. The Client acknowledges satisfaction and completion with all elements of the project/phase_
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ \_\_\_\_\_**_MM/DD/YYY_**\_\_\_\_ \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
_Client Representative Signature Date DevCom's Representative Signature_
# Project Kick-off (Template)
The internal meeting involves Devcom representatives and possibly known team members.
Please check the [**General Guidelines**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7502) for more information.
TEXT in **_bold_** **_italic orange (_****_including links in_** **_light blue_****_)_** is meant to be adopted by each project.
## **_Project_** **Kick-Off Meeting Summary**
### **Protocol**
Meeting date: **_MMMM/DD/YYYY_**
Participants: **_a list of participants_**
## **Customer Details**
Customer Name:
Customer Contact Person: **_the name of a person and role_**
Customer Website:
## **Project Details**
Project Name:
Short description of the project:
Budget Type: **_Fixed or rate per hour_**
Timeline:
Tools & Technologies:
## Results of Meeting
AM:
Rate:
Team:
Project administrator:
PM:
BA:
# Regression Testing Flow
Before and after every deployment to Production (and/or other Environment where DOD is applicable), the QA procedures must be executed to verify the successful release
TEXT in **_bold_** **_italic orange (_****_including links in_** **_light blue_****_)_** is meant to be adopted by each project.
# Guideline
* QA representative or assigned person must log in to the Production (and/or other Environment where DOD is applicable) Environment. Credentials can be found on the **_Confluence page_**
* Testing must be started no later than **_11:30 AM UA time_**
* The QA representative or assigned person must conduct the test and record any issues that have to be fixed
* After issues are found, they are prioritized and planned using the [**_Forecast document_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3881)
* The most critical ones are marked with the **HIGHEST** priority and are being worked on immediately. The rest go either in the next Sprint or backlog (improvements)
* The report is distributed by **_7:00 AM EST_** with the current status:
* Number of issues and their severity
* The possible root cause for each issue
* Plan for hot and hard fixes
* The last thing is to assign responsible people to execute the planned work.
The results are stored within the **_Confluence page_** with a subsequent hierarchy depending on the date, Environment, and component.
# Risk Management (Template)
Please check the [**General Guidelines**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7022) for more information
A risk event is an unidentified event that may or may not happen. It can have positive (opportunities) or negative (threats) impacts on the project if it does happen.
The risk management process is very iterative!
Uncertainty can be presented in various forms:
* Risk is associated with not knowing future events.
* Ambiguity is associated with not being aware of current or future conditions.
* Complexity is associated with dynamic systems having unpredictable outcomes.
* Volatility is associated with unstable conditions and/or a state of events.
When all actions to soften the impact are executed, the contingency plan comes. But the best strategy is to be proactive rather than reactive. Try to prevent the risk from happening and evaluate the efforts (resources to be allocated to soften the impact) before any action occurs.
Spend a moment thinking about how risk response planning might lead to updates to the schedule, cost, quality, procurements, communications, human resource management plans, and the project's scope, time, and cost baselines.
# Risk Register Template
[https://docs.google.com/spreadsheets/d/1NAdaHfhM803a4ukZgaUBXXTk8VJUSoiZdZ1xsORja4Y/edit?usp=sharing](https://docs.google.com/spreadsheets/d/1NAdaHfhM803a4ukZgaUBXXTk8VJUSoiZdZ1xsORja4Y/edit?usp=sharing)
# Root Cause Analysis (Template)
Please check the [**General Guidelines**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7182) for more information
TEXT in **_bold_** **_italic orange (_****_including links in_** **_light blue_****_)_** is meant to be adopted by each project.
# Template
| **ISSUE START DATE:** **_MM/DD/YY_** | **ISSUE END DATE:** **_MM/DD/YY_** | **AFFECTED PARTIES:** |
| ---| ---| --- |
| **THE ISSUE:** | **RCA #:** |
|
**EVENT DESCRIPTION**
|
|
|
|
**TIMELINE**
|
| **DATE** | **TIME (****_TIMEZONE_****)** | **EVENTS LOG** |
| | | |
| | | |
| | | |
| | | |
| | | |
# Scrum Assessment Tool
[Ukrainian version of this guideline](https://docs.google.com/document/d/15Ya9_-Qmp2Y6iLMjYHngBJlbVS_FAJ_gu6EDolMxAW4/edit)
# Guideline
## Product Owner Engagement
The **Product Owner** is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
The **Product Owner** is also accountable for effective Product Backlog management, which includes:
* Developing and explicitly communicating the Product Goal;
* Creating and clearly communicating Product Backlog items;
* Ordering Product Backlog items; and,
* Ensuring that the Product Backlog is transparent, visible, and understood.
His engagement includes:
* Paying close attention to the demos and providing feedback to the team.
* Offering high availability to the Scrum team to answer any questions that arise. They are ready to attend demos and accept user stories as **DONE**.
* Doing the above work or may delegate the responsibility to others. Regardless, the **Product Owner** remains accountable.
For **Product Owner**s to succeed, the entire organization must respect their decisions. These decisions are visible in the content and ordering of the Product Backlog and through the inspectable Increment at the Sprint Review.
The **Product Owner** is one person, not a committee. The **Product Owner** may represent the needs of many stakeholders in the Product Backlog.
## Scrum Master-Servant Leader
The **Scrum Master** works with the Scrum team and guides them in their journey to adopt Agile and Scrum principles. The **Scrum Master** is not a boss or a project manager but a [servant leader](https://www.greenleaf.org/what-is-servant-leadership/).
Some attributes of a Scrum Master as a servant leader are as follows:
* Makes observations and asks questions about things that violate Scrum and Agile principles and helps people overcome obstacles on their own.
* Provides direct and firm feedback.
* Understands that change is difficult and employs empathy while guiding the team in making the necessary changes in behavior.
* Acknowledges when things are outside their scope of knowledge and skills and recommends other avenues when appropriate.
* Builds relationships with the team and becomes a trusted advisor to them.
* Coaches the team to become self-organizing and cross-functional.
* Helps the Scrum Team focus on creating high-value Increments that meet the Definition of Done.
* Facilitates meetings and encounters, does not directly tell people what to do, and helps people gradually change their own behavior.
* Causes the removal of impediments to the Scrum Team’s progress; and,
* Ensures that all Scrum events take place and are positive, productive, and kept within the timebox.
## Stable Cross-Functional Team
A scrum team focuses 100% on the work in a sprint:
* They do not perform any other work.
* The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people.
* **Scrum Teams** are **cross-functional** (**T-shaped** skills), meaning the members have all the skills necessary to create value for each Sprint.
* They are also self-managing, meaning they internally decide who does what, when, and how.
* The Scrum Team is responsible for all product-related activities, from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required.
## Definition of Done
One of the twelve principles of the [Agile Manifesto](https://agilemanifesto.org/principles.html) is “Working software is the primary measure of progress.”
The [**Definition of Done**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5341) expands this idea and defines the exact criteria that allow a user story to be considered **DONE**. From a delivery perspective, these criteria typically include “fully developed”, “QA-tested,” and “deployable”. They can also include additional elements, such as “unit-tested,” “code-reviewed,” and “stress-tested.” The team identifies the completed criteria together. The final **DONE** criteria item is accepted by the product owner.
The moment a Product Backlog item meets the **Definition of Done**, an Increment is born.
The **Definition of Done** creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the **Definition of Done**, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.
## Task / User Story Definition
The most efficient Scrum teams define **user stories** using the [INVEST](https://www.pivotaltracker.com/blog/how-to-invest-in-your-user-stories) approach. The most important letters from this acronym are **I** (independent), **N** (Negotiable), **V** (Valuable), **E** (estimable), and **S** (small), **T** (Testable).
When stories are independent of each other, there is much more flexibility in how they can be developed and deployed.
Small stories are easier to understand and get to a **DONE** state in the fast-moving sprint execution cycle.
Pitfalls:
* When stories have tight dependencies, friction occurs, and stories are harder to deploy to production.
* When legacy monolithic systems are involved, the dependencies can be treated as technical debt and be prioritized on the backlog like any other **user story**.
* When stories are large, the likelihood of not completing stories in a sprint is higher. Often, these large, incomplete stories move from sprint to sprint, making planning difficult.
## Task / User Story Relative Size Estimation
To properly plan, we need an estimated backlog. A popular technique is to estimate user stories in a relative manner. The Definition of Done must be considered when **estimation** is performed.
The most common technique is story points. This technique assigns a point value to each user story using a Fibonacci-like format: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100.
[**Estimation**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4121) is done by the team. During a planning poker session, each team member votes for their estimate. A simplified approach known as **T-shirt size** may be used.
## Backlog Refinement
**Backlog refinement** is not a formal Scrum event. The goal of **backlog refinement** is to get the backlog into a state that will allow sprint planning to be successful. The frequency of this type of meeting is up to the team. The following activities should be accomplished:
* **Priority** – the priority of the backlog is reviewed and modified as needed.
* **Task** /**User Story Definition** – new or drastically changed stories are explained by the product owner. The team interacts with the product owner and asks any questions necessary for a full understanding.
* **User Story–splitting** – when a task/story is large, it is split into smaller stories.
## Sprint Planning
[**Sprint planning**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4001) is where the team decides what can be completed in the upcoming sprint.
This process is easy when the backlog has been properly refined. Velocity is used to help determine what stories will fit into a sprint.
* The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders.
* The Sprint Goal must be finalized before the end of Sprint Planning.
* For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done.
* Decompose Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers.
* No one else tells them how to turn Product Backlog items into Increments of value.
## Sprint Execution
Once a sprint has begun, it is largely up to the team to self-organize and successfully deliver the user stories agreed upon during the sprint planning.
There is one daily meeting required in the Scrum process. This meeting occurs each day at the same location and is time-boxed to fifteen minutes.
During the meeting, each team member discusses what they have worked on since the last meeting and what they plan to complete by the next one. They also mention any impediments they have.
The team also reviews the progress of the sprint using a burndown chart.
This meeting provides the team with a daily view of the work remaining in the sprint.
Sprint execution is where the rubber hits the road. Any deficiencies that occurred are exposed here.
## Sprint Review
The [**Sprint Review**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4381) is where the team demonstrates the scope that is **DONE**, awaiting the Product Owner's approval, and progress toward the Product Goal is discussed.
* The team decides who will perform the demonstration.
* The product owner is a key attendant to the meeting because he must approve the **DONE** items.
* We do not have to wait until the sprint review to demonstrate stories; they may be demonstrated to the product owner anytime and be approved.
* Unapproved stories move to the next sprint and get entangled with the stories that are planned, which causes unnecessary noise and distraction.
## Sprint Retrospective
The [**Sprint Retrospective**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5421) is where the team reflects on the sprint that just ended and identified a few things that went well and a few that need improvement.
* The Team continues doing the things that went well and improving on the things that did not go so well.
* The team agrees to improve two or three things in the next sprint.
* The team embraces the retrospective step and improves over time.
* The Scrum Team identifies the most helpful changes to improve its effectiveness.
## Increment
An **Increment** is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior **Increments** and thoroughly verified, ensuring that all **Increments** work together. In order to provide value, the Increment must be usable.
Multiple **Increments** may be created within a Sprint. The sum of the **Increments** is presented at the Sprint Review, thus supporting empiricism. However, an **Increment** may be delivered to stakeholders before the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.
Work cannot be considered part of an **Increment** unless it meets the Definition of Done.
# Assessment Review
If you have a 1 in any of these areas, your Scrum outcome will be negatively affected. If there are many 1 point areas, consider pausing delivery for a short period of time and developing an action plan to improve them.
The areas are ranked from **1 - 5**:
* **44 - 60** – the team is quite accomplished in its adoption of Scrum. Some things to look into:
* Do you have a stable velocity? Look at the past five sprints and see if it is consistent.
* What is the quality of your product?
* Are your customers happy?
* **28 - 43** – you are probably following the mechanics of Scrum but not the true essence of it. Look at one or two of the lowest ranks. Use Retrospectives to discuss and improve.
* **11 - 27** – some real work is needed. Have a team meeting and a frank discussion about the issues that resulted in a low score. If you do not know where to start, you may want to hire an Agile coach to help guide the team down the correct path.
# Assessment Template
[https://docs.google.com/spreadsheets/d/1w5BW7SWPP45GdOs79XajK2HDGxZCJC7yeqpbUp0HCjw/edit#gid=0](https://docs.google.com/spreadsheets/d/1w5BW7SWPP45GdOs79XajK2HDGxZCJC7yeqpbUp0HCjw/edit#gid=0)
# Sprint Review Template
Please check the [**General Guidelines**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4381) for more information
TEXT in **_bold_** **_italic orange (_****_including links in_** **_light blue_****_)_** is meant to be adopted by each project.
# Template
### Sprint _#_ Review
| **Date** | _MM,DD,YYYY_ |
| ---| --- |
| **Items and action points to consider** | _Recording link_ |
| **Team velocity** | |
### Sprint Feedback
1. **_Feature A_**
1. _Presenter:_
2. _Environment:_
3. _Description:_
4. _NOTE:_
2. **_Feature B_**
1. _Presenter:_
2. _Environment:_
3. _Description:_
4. _NOTE:_
3. ...
# Sprint Retrospective Template
Please check the [**General Guidelines**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5421) for more information
TEXT in **_bold_** **_italic orange (_****_including links in_** **_light blue_****_)_** is meant to be adopted by each project.
# Single Scrum Team Retrospective Template
### Sprint **_#_** Retrospective
| **SPRINT START & END DATE** | Start: **_MM,DD,YYYY_** & End: **_MM,DD,YYYY_** |
| ---| --- |
| **TEAM** | |
| **PARTICIPANTS** | |
| **PERSON** | **WHAT WENT WELL** | **WHAT COULD HAVE GONE BETTER** | **WHAT DO YOU WANT TO TRY NEXT** | **WHAT PUZZLES US** |
| ---| ---| ---| ---| --- |
| | | | | |
| | | | | |
# STAR Retrospective
For this approach, one needs a broad to visualize or create a list with the following items to discuss and record:
1. **KEEP**
2. **LESS**
3. **MORE**
4. **START**
5. **STOP**
# Scaled Scrum Team Retrospective
### **Because there are common scaling dysfunctions, every Retrospective should address the following questions**
* Has the Team met the Sprint Goal? If not, why not?
* Was any work left undone? Did the Team generate technical debt?
* Were all artifacts, particularly code, frequently (ideally, continuously) and successfully integrated?
* Was the software successfully built, tested, and deployed often enough to prevent the overwhelming accumulation of unresolved dependencies?
### **When issues are discovered, the representatives need to ask**
* Why did this happen?
* How can the issue be fixed?
* How can recurrence be prevented?
After the Retrospective meeting where Integration Team participates, it is important to define the action items to work on within all Scrum teams. The Integration Team has to keep track of such items and may use a table tool to keep working on items of improvement.
# Template
| **PLAN** | **DO** | **CHECK** | **ADAPT** | **DONE** |
| ---| ---| ---| ---| --- |
| _Improvement ideas to be discussed and possibly investigated_ | _Things the Integration Team has agreed to do_ | _Things that are ready for the Integration Team to evaluate_ | _Things that have been evaluated but need to be adapted before they are ready to adopt_ | _Improvement ideas have been implemented_ |
| | | | **_Bug fixing (success = dedicate 10% of capacity to fix the scope of Regression testing in pre-release Sprint)_** | |
| **_Backlog grooming (success = review 20 tasks and their applicability each Sprint)_** | | | | |
“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
_Norm Kerth, Project Retrospectives: A Handbook for Team Review_
# Stakeholder Management Template
# Stakeholder Register
Please check the [**General Guidelines**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3721) for more information
TEXT in **_bold_** **_italic orange (_****_including links in_** **_light blue_****_)_** is meant to be adopted by each project.
# Template
| **NAME**
| **ROLE**
| **CONTACT INFO** | **IMPACT** | | | |
| ---| ---| ---| ---| ---| ---| --- |
| **Requirements** | **Expectations** | **Responsibilities** | **Involvement** | | | |
| | Account Manager | | | | | |
| | Project Manager | | | | | |
| | Tech Lead | | | | | |
| | Developer | | | | | |
| | QA | | | | | |
## Legend of Involvement section
### **Low**
* Prefer to be contacted rarely;
* Know specific information;
* Represent a specific segment of users;
* Random activities, consultations;
* Do not make decisions alone.
### **Medium**
* Prefer to be informed a few times per phase/iteration;
* Know how some parts of a product can interact;
* Represent managerial roles;
* Want to have scheduled short appointments;
* Like keeping an eye on a product roadmap.
### **High**
* Prefer to be involved in every meeting;
* Possess a lot of useful information;
* Represent C-level, a project sponsor, head of a department;
* Interested in communication, interaction, and collaboration with vendors;
* Ensure a project is on track;
* Decision-makers.
# Example
| **NAME**
| **ROLE**
| **CONTACT INFO** | **IMPACT** | | | |
| ---| ---| ---| ---| ---| ---| --- |
| **Requirements** | **Expectations** | **Responsibilities** | **Involvement** | | | |
| **_Richard Handsome_** | **_Project sponsor (Industry expert)_**
| [**_richh@project.com_**](mailto:richh@project.com) | **_Quarterly Milestones execution_** | **_In-time delivery_** | **_Define the most valuable features; pay invoices_** | Medium |
| **_Garry Neville_** | **_Product Owner_** | [**_garyn@project.com_**](mailto:garyn@project.com)
**_skype: garrnev_** | **_Development Team chooses the way and tools to meet quality standards_** | **_Development Team assesses tasks feasibility and raises flags when risks occur_** | **_Provide details for tasks; prioritize the backlog items_** | High |
| **_Andrew Tompson_** | **_Head of Support_** | [**_andyt@project.com_**](mailto:andyt@project.com)
**_skype: atom\_pson_** | **_Provide analysis of support requests based on categories every Monday_** | **_Development Team reacts to support tasks according to agreed rules_** | **_Prioritize and send requests from users through the Help desk; suggest features based on users' requests_** | High |
# Statement Of Work
A Statement of Work (SOW) is made at the project outset and outlines everything that needs to go into a project.
The statement of work is a legally binding document that captures and defines all the aspects of the execution of the project scope of work. It contains the activities, deliverables, and timetable for the project. It’s a highly detailed work contract that defines the terms and conditions agreed upon between parties and lays the groundwork for the project plan.
SOW is prepared using the [Proposify](https://app.proposify.com/login) tool.
# Template
[https://docs.google.com/document/d/1Vv\_968q3cNCNcQViFlAbnshFCLb7Gvhg6eq-LDKvipk/edit](https://docs.google.com/document/d/1Vv_968q3cNCNcQViFlAbnshFCLb7Gvhg6eq-LDKvipk/edit)
# Team Stages (Template)
Please check the [**Guidelines**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-9201) for more information.
# Evaluation
To define the stage of any team, one can ask questions or grade the statements below on a scale from 1 to 4. Frequency: at least bimonthly.
* 1 - no or very low adoption
* 2 - low adoption
* 3 - mediocre adoption
* 4 - very high adoption
1. We try to establish procedures or protocols to ensure everything is in order and working properly (e.g., remove blockers, everyone gets a chance to speak, we know how to convert requirements into deliverables)
2. We cope with tasks quickly and do not spend too much time planning.
3. We all understand that we are a team and share the responsibility for success or failure together.
4. We have thorough procedures for reconciling our goals and planning how we will execute our tasks.
5. Team members are afraid or reluctant to ask others for help.
6. As a team, we understand the goals and objectives.
7. The team leader tries to support the processes and facilitates task execution.
8. We do not have fixed procedures; thus, we compile them as the task or project progresses.
9. We generate many ideas but do not use and reject many of them because we are unable to understand them fully.
10. Team members do not fully trust other members and closely monitor others working on specific tasks.
11. The manager ensures that we follow the processes, do not argue, do not interrupt, and adhere to the essence of those processes.
12. We like to work together; we have fun and spend time productively.
13. We accepted each other as a member of the team.
14. A team leader is open-minded and cooperative.
15. We determine the goal and what tasks need to be performed to create value.
16. Many team members have their own ideas about the processes.
17. We fully accept each other's strengths and weaknesses.
18. We assign specific roles to team members (team leader, facilitator, demo presenter, etc.).
19. We try to achieve harmony by avoiding conflicts.
20. Tasks are very different from what we imagined and seem very difficult to complete.
21. There are many abstract discussions about concepts and issues that not everyone likes.
22. We can solve group problems.
23. We argue a lot, although we agree on important items.
24. The team is often tempted to go beyond the initial scope of the project.
25. We express our opinion structurally.
26. The team has a sense of close working relationship.
27. It seems that only a few project goals have been achieved.
28. The goals we have set seem unrealistic.
29. Although we are not completely sure about the goals and problems of the project, we are happy and proud to work in a team.
30. We often share personal problems with each other.
31. There is strong resistance to task execution and quality improvements.
32. We are ready to work extra time when required.
| | **FORMING STAGE** | **STORMING STAGE** | **NORMING STAGE** | **PERFORMING STAGE** |
| ---| ---| ---| ---| --- |
| | **Question** | **Score** | **Question** | **Score** | **Question** | **Score** | **Question** | **Score** |
| |
1
| |
2
| |
4
| |
3
| |
| |
5
| |
7
| |
6
| |
8
| |
| |
10
| |
9
| |
11
| |
12
| |
| |
15
| |
16
| |
13
| |
14
| |
| |
18
| |
20
| |
19
| |
17
| |
| |
21
| |
23
| |
24
| |
22
| |
| |
27
| |
28
| |
25
| |
26
| |
| |
29
| |
31
| |
30
| |
32
| |
| **TOTAL** | | | | | | | | |
## Legend
The highest score of one of the four stages indicates at what stage a team works. If the highest score is 32 or more, this means the team's current stage.
The lowest score among the rest three stages means that a team is not in this state. If your lowest score is 16 or less, it strongly indicates that a team is not working as it might in that particular stage.
When the two scores are very close (up to 5 points difference), a team is probably going through a transition phase from left to right.
If there is only a tiny difference between three or four stages (up to 5 points), there is no clear perception of what is happening in a team, performance is very volatile, or a team is in the Storming stage.
# [DRAFT] Custom Framework (NERD)
NERD stands for the **Nodal Ethics of Robust Development,** a custom-built agile framework for software development using adapted approaches, real-life practices, and day-to-day activities.
# Code of Conduct - STAR
_We do not need stars in the team; we need the star team._
## Stewardship
A **Steward** role is being a humble leader from the NERD perspective in software development. Stewards act on behalf of the group of stakeholders, subject matter experts, and other practitioners as they have their support. They carry out various activities that focus primarily on people management:
* **they care** about each team member first and then about a project. People are the most valuable and expensive asset. Regardless of the role, faithful stewards are always there to help;
* **they make transparent** goals, processes, plans, environments, and current project state. It allows everyone to be on the same page;
* **they follow** company policies to match the expectations of a steering committee and project goals. As various roles are involved in a project, every person can lead the particular process (e.g., quality practices, management practices, development practices, security practices);
* **they possess** the ability to coordinate actions with others while influencing their behavior. Empathy and leadership are the key factors in achieving this.
By default, they represent leadership positions, such as team lead, tech lead, QA lead, front-end lead, back-end lead, and project manager. More than one team member can become this steward when promoting processes, practices, principles, sharing industry standards, etc.
## Trust
Any team goes through several phases until it can perform at the highest level. The key to success is **trust**. A good self-managed **team** consists of people who possess complementary skills, trust each other, and commit to a common goal. Hence, they hold themselves mutually accountable. The team may also choose the leader, someone to coordinate actions and facilitate all the processes. But one of the primary roles of any leader is to enable an environment where no one depends on his presence. Moreover, every team member has to be ready to lead and follow at any time, regardless of the current position of being a developer, PM, QA, etc.
It allows for delegating responsibilities when needed and where applicable; thus, no one is a bottleneck, and there is always a backup plan. This delegation depends on the relationship among people. Empowering others eradicates micromanagement and promotes the leadership of every team member, trusting the local decisions they make. As one may think, it creates the environment of entrusted followers ready to provide support and take a full or partial lead when required.
Nevertheless, stakeholder management is also about openness and shared understanding, as everyone is in the same boat and influences a project. Together they establish agreements on how to cooperate:
* The more confidence, courage, and integrity are demonstrated at the start, the more trust stakeholders experience.
* Deeds speak louder than words, so say what you mean and mean what you say.
* Reciprocity is part of a solid relationship, which entails "give first and be ready to receive."
* When team members are allowed to be vulnerable and open to others without having to protect themselves defensively, they feel safe and demonstrate empathy, admit failures, and ask for help.
To build trust, team members first take small steps and take on small commitments, and then, as it grows, they will be ready to accept bigger commitments.
## Adaptability
Changes are inevitable in every project. The team's flexibility is essential. It defines how any team executes the project, acts in unexpected cases and behaves when things go off plan.
On the one hand, it means more than just adjusting the requirements changes, but instead being proactive and foreseeing the upcoming events. Further planning of these events makes them part of the routine during the adaptation.
On the other hand, adaptability refers to a product or service itself and how the stakeholders generate value while considering the market changes. The whole business strategy may shift in one moment, causing the domino effect. Alternatively, there is always a way to adjust the purpose, processes, and even people. That all starts with education, but every stakeholder is different.
* Usually, a **Client** responds to changing conditions promptly, but it has to be reconciled with other project activities. Just as stewards care about each team member, they ensure all stakeholders (Devcom and Client) are on the same page. They educate them on how value is created by explaining why and how the processes work. It brings clarity and creates a proper environment for better Client engagement.
* **Team**. We believe that team's morale depends on three key components: **clear objectives**, **recognition** when someone goes above and beyond, and continuous **knowledge sharing**. The last one enables suggestions to improve the processes and workflows and even adapt practices from other areas. Once they do it successfully, they stick with 'good' and look for 'better'.
* **Project**. Adding features to the product usually helps more users meet their expectations. However, it might be different when a business radically alters its initial plan. The ship starts to rock, and everyone should be ready for this. Just recall how the pulp mills Nokia company became one of the best cell phone manufacturers in the 2000s.
* **Technology**. The industry innovations surpass its achievements. A few years ago, the technology stack chosen could be considered outdated and even hard to support. After selecting the right frameworks, one should periodically study the second option to ensure a smooth transition when an opportunity shows up.
## Ramp-up
As a team adapts to innovations, processes, and changes, it declares its way to continuous improvement. There is always room for it; however, every steward should promote changes depending on the project's or team's current needs. Just like any other task has its priority, the suggested initiative may be accepted and implemented based on the value it can create soon.
The pile of features in the project backlog often creates an illusion of infinite work. That is why refinement is essential in bringing back the focus, and a team can plan only the most critical tasks to date. Stewards monitor obsolete items, report them to decision-makers, and emphasize the importance of scope forecasting in the short term. In addition to that, other processes should be reassessed periodically, like resource planning and release, go-live plan and further support, and risk management. As we operate in a quickly shifting environment, such activities may cause difficulties and create blockers if not processed timely.
Every professional does their job well, but a good team member can always support other activities if a primary executor is unavailable. It is the ability of T-shaped team members as they understand different perspectives. As team members learn each others' domains during various events (planning meetings, retrospective meetings, daily meetings), they may discover weaknesses of project processes at some level:
* Everyone can contribute when conducting **analysis** and **planning** activities;
* Provide feedback when **designing** a part of the product and/or **prototyping** a big feature;
* Assess the quality of requirements when **writing a code** and **reviewing** it;
* Perform the product **testing** at different stages and **support** it after the initial release.
Rapid feedback can speed up the implementation of potential improvements, eliminate waste, and move a project forward. These are signs of a **culture of continuous improvement**.
# Nodes
Think of a project as some infrastructure with Nodes connected by railways. Every Node is a set of institutions, depots, warehouses, control rooms, and other buildings required to support the operations within that infrastructure. The railways are the transitions among the Nodes.
Nodes represent the required efforts in the manner of a cohesive collection of **Methods**, **Artifacts**, and **Pointers (MAP)** to complete a set of activities.
* ⚙️**Methods** \- _Events, processes, practices;_
* 🛠️**Artifacts** \- _Documentation, deliverables, tools;_
* 🧭**Pointers** \- O_utcomes, metrics._
## Implementation
Everyone has to be on the same page before implementing NERD. Every stakeholder must know the abovementioned Code of Conduct (STAR).
* Go through the explanation of **Nodes** constitution down below.
* Visualize what is already known and present by drawing the initial artifact, the "**NERD's Pentagram**," with Nodes using a paper or any other digital tool.
* Quick projection of the known details helps identify what is known and missing to complete the accurate Pentagram.
* Cooperate with stewards and choose wisely the methods, artifacts, and pointers at each Node. For instance, the business analysis should be executed according to the template and possibly adjusted considering the project specifics.
* Set up the Nodes together and determine the missing or incomplete **MAP** items. Stewards can always add, modify or improve them as the project advances.
* Start the activities to run the processes, create artifacts and begin the trip among Nodes.
# Node 1. Preparation MAP
## Planning activities
**METHODS**
\- Business Analysis
\- Planning Process
\- Development Process
\- Scope Estimation
**ARTIFACTS**
\- Contract/Agreement
\- SOW
\- Stakeholder Management Plan
\- Communication Plan
\- Requirements Management Plan
\- Technical Blueprint
**POINTERS**
\- Quality Standards
\- Performance Baselines
## Build a Node
The first thing you do with your team is assessing the available resources using **Business Analysis** techniques. That may include current **agreements**, the project's status to date, and any requirements presented by the Client. These are inputs for the **Planning activities** where new artifacts will be created and adapted, such as:
* **Stakeholders management plan**. It is nice to have a single **Client representative**, the **Keeper**, who leads a single stream or a project and makes decisions on behalf of the Client's group or committee;
* **Communication plan**. It is a must-have artifact to approve the meetings, their purpose, frequency, people involved, and means of communication;
* **Requirements management plan**. It is essential to have an agreed process of creating, processing, and delivering them promptly.
Another piece in the 1st Node is the organization of the **Development process,** where well-known SDLC is adjusted to the strategy of creating value as quickly as possible. During this process, not only the **Estimation** technique is chosen, but the scope workflow is designed, the development cadence is approved, and plans of continuous integration and improvements are drafted. These activities prevent the potential waste of efforts on the **Execution Node**.
The **Technical Blueprint** should lay out the main code conventions, system architecture, rules, and attributes the team follows when writing code. It includes how methods, classes, and other variables are named, the unit test approach, etc.
**Quality standards** and its baseline guarantee the team is not off its course as they point to the project's end goal. Project **Performance** is part of the qualitative opinion but has primarily quantitative indicators to evaluate the software development.
## Tip
Stewards may choose any agile framework or separate practices that fit the **Preparation Node**.
# Node 2. Execution MAP
## Execution activities
**METHODS**
\- Daily Sync
\- Requirements Management Process
\- Refinement Process
\- Continuous Delivery
**ARTIFACTS**
\- Backlog of Tasks
\- Quality Management Plan
**POINTERS**
\- Goal
\- Project Objectives
\- Definition of Done
## Build a Node
The agile approach is handy where the unknowns take place. NERD implies short-term intervals to complete the development cycle in batches to focus on the essential items, like in Scrum. Since each interval (one may use the analogy with a 'sprint') has its purpose and outcomes, it is vital to have regular team checkpoints, such as the **Daily sync**. It assures the current work is under control and the team makes progress. The team should define the length, agenda, and other attributes of these short meetings.
**Requirements management** encompasses activities to work with business requirements and create a backlog of items for further execution.
The **Refinement process** is a litmus paper indicating whether efforts should be split between regular development and defining the 'unknowns' (VUCCA):
* Volatility;
* Uncertainty;
* Unpredictability;
* Complexity;
* Ambiguity.
The refinement is an essential part of the **Execution Node** and must be held regularly to verify that '_planned tasks are not VUUCA tasks_'; however, the effort planned for these activities may vary per interval and the level of 'unknowns'.
Continuous integration is one of the XP practices that keeps code healthy and up-to-date so that integrating big features won't cause any issues. A **Continuous Delivery** pipeline allows having on-demand releases upon availability.
Based on the **MAP** of the **Preparation Node,** it becomes easier to execute the **Tasks from the Backlog** and use baselines from the **Quality management plan** as guidelines. Every steward does his part of the job throughout the interval to reach the announced **Goal**.
The main achievement of the refinement process is ultimately the refined scope:
* the unknowns are clarified;
* tasks are prioritized depending on urgency and value;
* obsolete items are removed from the product backlog;
* and what is even more important - the **Project Objectives** are updated.
Compliance with the **Definition of Done** is the best indicator of completion for any stakeholder. It describes the deliverables as accomplished, and everyone understands why.
## Tip
Continuous integration has its benefits and downsides. At a glance, that implies more testing, like performing smoke tests as the first rapid check of successful integration, but it definitely pays back later.
# Node 3. Monitoring MAP
## Monitoring activities
**METHODS**
\- Scope Forecasting
\- Risk Management Process
\- Knowledge Sharing
**ARTIFACTS**
\- Change Management Plan
\- Release Plan
**POINTERS**
\- Project Scoresheet
## Build a Node
Since the iterative approach works better regardless of the cadence, the upcoming interval should be **forecasted, checked, and prearranged**. These activities aim to minimize the planning efforts in the 1st Node during the recurring meetings where a Client outlines the main goals.
The VUCCA items are the key elements of **Risk Management**. The team has to revisit them regularly to check the triggers and verify and add new items, just like during the iterative task planning process.
Continuous **knowledge sharing** removes bottlenecks and reduces the risks of generating dependencies, tech debt, and redundant functionality. It is recommended to have formal and informal (team building) gatherings to share the information.
As any project must be prepared for rapid change, the **Change Management Plan** not only serves as a guide to the team but is the predecessor of a **Release plan**. The last one refers to available changes for end-users, primarily defining the frequency.
**Project scoresheets**, KPIs, and metrics are those pointers to ensure the current interval or phase is on track while monitoring the activities, processes, and outcomes. We still believe what can be measured can be managed. Historical data is especially valuable for long-term projects.
## Tip
Small releases are easy to deliver and manage (support, rollback, upgrade).
# Node 4. Action MAP
## Reviewing and coordinating activities
**METHODS**
\- Review Process
\- Retrospective Process
**ARTIFACTS**
\- Lessons Learned Register
\- Agile/Team's Charter
**POINTERS**
\- Refactoring
\- Incremental Change
## Build a Node
Each interval has deliverables and items to argue and/or agree upon. The team **demonstrates** and **reviews** the completed work periodically to understand the room for improvement during the next interval.
On the one hand, it is recommended to schedule events to keep the rhythm and focus on current activity, like a **Retrospective** meeting. On the other hand, no need to wait until the process is complete or a phase is over because no one likes waste. Stewards may collaborate immediately.
The feedback received during such activities is a perfect input to plan action items for further progress and create a **Team charter** and/or **Lessons learned register**. This documented code of conduct keeps the team's spirit at the highest level as it regulates team members' behavior and agreements.
Every software update creates **incremental changes** during the intervals and must create value. Along with the speed of development and desire to push new features to the end-users, stewards must dedicate some effort to **refactoring** to compensate for the tech-debt impact.
We also agree with Norm Kerth, who said that "regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand_"._
# Node 5. Reiteration MAP
## Reflection/summary activities
**METHODS**
\- Analysis
\- Improvements
\- Strategy Review
\- People Management
**ARTIFACTS**
\- Project Roadmap
\- Strategic Goal
**POINTERS**
\- Embrace the Change
\- Maintenance & Support
## Build a Node
The **Analysis** and **Improvement** plan is based on the collected data during the activities of the first four Nodes, similar to the PDCA (plan, do, check, act) cycle. Action items are the output and must have deadlines, measurable outcomes, and responsible executors.
Every project has its mission or goal. Stakeholders should perform the interim reviews not only for the work done within intervals but also look at the market, asking themselves, "Is this still a valid **Strategic goal**?". Stewards make decisions with a logical and data-driven background using various metrics, like the lead time of similar features based on the efforts. The **Project roadmap** with milestones can be revised and adjusted depending on the answer.
**Changes** are not easy, especially those that may deviate from the initially planned target. The readiness to accept the change is a perfect indicator of how everyone can adapt as it impacts the business. It is not the project which requires this evolution and embracing the change but the people behind it. Strong **People management** skills help stewards easily overcome the most challenging adaptation times through trust and adaptability.
One of the essential items in SDLC is the **Maintenance and support** process. After the in-house development, the deliverables of the project become available to the end users. Proper communication with them always brings insights into further upgrades, solves their pain points, and creates real value that aligns with the project's strategic goal.
## Tip
Any method, artifact, or pointer can be adjusted and added to each Node as an outcome of the **Reiteration**. When executing action items, utilize the OODA (observe, orient, decide, act) loop, the decision-action framework.
# The Visual Concept
[https://lucid.app/documents/embeddedchart/3145cb7f-91c8-431d-8f1c-b206dca1a3d8#](https://lucid.app/documents/embeddedchart/3145cb7f-91c8-431d-8f1c-b206dca1a3d8#)
# [DRAFT] DevCom PM Onboarding
# Welcome To DevCom
## About us
Established in 2000, DevCom is a full-cycle custom software engineering firm with headquarters in Ukraine (Lviv) and the USA (Florida). The company handles project development throughout the entire lifecycle: starting with **strategic planning** and **UX/UI design**, through **application development** and **quality assurance**, to **technical delivery**, **production maintenance**, and **support** \- all delivered with speed and agility to effectively support businesses in dynamic markets.
We comply with the latest development and technology standards and apply effective software engineering methodologies and integration procedures.
Our **goal** is to provide excellent IT services that meet our clients’ needs, timeframes, and budgets without compromises. We take pride in every solution we’ve developed and cheer at the success of every client we’ve helped. If there is a way we can help you meet your goals with software, don’t hesitate to drop us a line.
**Let's do IT together!**
## Mission and Values
At DevCom, we’re all about developing the highest quality software, strong ties with our team members, and robust partnerships with our clients. The number of years in the software development business is something to be incredibly proud of for DevCom. A combination of new technologies, commitment, team knowledge, and business ideas of our clients results in functional business solutions with a global reach. It’s what fuels our drive.
We work hard to help enterprises accelerate in adopting new technologies, untangling issues that follow digital evolution, and orchestrating continuous innovation.
### Our mission
DevСom provides innovative, reliable, and cost-effective information technology solutions and technical services exceeding our customers' expectations.
And we remain fully committed to it.
### Our values
These values are the heart of DevCom. They guide our actions every day and shape the future we’re building together with our clients:
* **Working with people who make a difference**. We seek out people who challenge themselves to make a difference - and champion that spirit of being exceptional in others. As friends, we work together as a strong team to create value that delivers unparalleled results for our company and clients.
* **Building trusted relationships**. Over the last twenty years, our team has grown to become a big, welcoming family, and we treat our clients as a part of our family too. We’re dedicated to making the goals and processes transparent, which helps us resolve issues quickly and openly.
* **Technical excellence - above all else**. We foster a culture of quality through a rigorous process and team responsibility that can comfortably commit to exactly what it can deliver. For us, genuine success means having a more predictable process, happier customers, and technical excellence - it is above all else. And delivering the best possible quality of software is our core value.
* **Orchestrating continuous innovation.** The industry progresses rapidly, and we have moved through many changes with our Clients. Whenever we incorporate new technologies, we do in-depth research and ensure we have the knowledge and the skills to move forward with the projects.
**BOD**
**↓**
**CEO**
↙ ↘
**Operations Shared Services**
↙ ↓ ↘ ↙ ↙ ↓ ↓ ↘ ↘
**Unit 1 Unit 2** **Unit 'N'** **Office Support HR Finance Tech Support CTO** **PMO**
Img. 1. DevCom's simple structure
## Timeline
**TO DO**
**2000**
* Major events that took place and made a huge impact on the company's life
* Memorable events
* Major events that took place and made a huge impact on the company's life
* Memorable events
**2005**
**2009**
* Major events that took place and made a huge impact on the company's life
* Memorable events
* Major events that took place and made a huge impact on the company's life
* Memorable events
**2014**
**2018**
* Major events that took place and made a huge impact on the company's life
* Memorable events
* Major events that took place and made a huge impact on the company's life
* Memorable events
**2020**
# Project Management Office
## Purpose
The **Project Management Office (PMO)** at DevСom represents a management division that standardizes project-related governance processes, facilitates sharing of resources, tools, existing techniques, and methodologies, and develops custom approaches with subsequent tailoring.
Its mission is to create an environment of sustainable high performance of projects and continuous improvement. Therefore, the [structure](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-6168) is flat:
**Director of PMO**
**↓**
**Project Managers––Project Coordinators––Project Administrators––Business Analysts**
And its principles are quite simple:
* Provide project management guidelines that support consistency in how projects are delivered
* Offer project support with shared services to successfully combine the development approach and life cycle
* Be the second pair of eyes to oversee the company's projects
* Serve as the center of growth, knowledge, compliance, and competence.
## Career path
A project manager's [life cycle](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4461) is ubiquitous and unique at every stage of the career path:
**Recruitment** → **Professional Development** → **Retention** → **Separation** → **Offboarding** → **Alumni**
1. **Recruitment** is part of the hiring process in collaboration with HR, where there are also a few sub-stages: attraction, interviewing, and onboarding.
2. **Professional Development**. We reckon that any project work strengthens PM qualities, hard skills, and leadership, allowing them to utilize the knowledge of principles, techniques, and frameworks.
3. **Retention**. The personal development plan (PDP) fosters a habit of continuous growth and being a T-shaped professional.
4. **Separation**. Leaving a project goes hand in hand with transitioning duties, cross-training for anyone who may need to take over a project, and passing responsibilities along with documentation.
5. **Offboarding**. The termination of work on a project is caused by various reasons, such as completion, the demand for a less/more mature project manager, or a 180° turn in his career path.
6. **Alumni**. We strive for the best-case scenario when a project manager performs at the highest level and is promoted to another position.
That is why we created our **custom evaluation system or so-called career matrix** that helps us develop highly skilled professionals. Becoming a project manager takes a lot of effort. The career path can start either as a planned goal or spontaneous activity.
**Project Administrator / Project Coordinator**
↓
**Project Manager (PM)**
**↙ ↘**
**Delivery Manager (DM) Senior PM / Program Manager**
**↘ ↙**
**Portfolio Manager / Account Manager**
**↓**
**COO / VP of PM**
Depending on the seniority level, the project manager shall pass the training and educate himself when starting the new role or advancing to a higher level of responsibility. For this purpose, everyone is welcome to use our internal knowledge base and custom training program.
## PM Documentation
Today [project documentation](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3821) is more than piles of e-docs to manage, control and deliver value. The list of documents varies by each project. The essential **three functions** substantiate it:
* to make sure that project requirements are fulfilled;
* to establish traceability concerning what has been done, who has done it, and when;
* to create visibility of processes.
The other benefits we see in having the project documentation are:
* faster new employee onboarding;
* better cross-team alignment;
* more effective knowledge sharing.
During each project stage, we want to create as many artifacts as needed, not as many as we may think of. Agile methods advocate "**just enough**" documentation and declare one of their values - working software over comprehensive documentation, and we 100% agree with it.
Every person in the team can help record our knowledge, agreements, requirements, and plans and put them in a digital form. Time is priceless, so let's use it wisely.
## Project Scoresheet
We aim to follow the plan, quickly make adjustments when needed, and work with the team effectively leading it.
**Project health** is a comparison of [key metrics](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4361) with baselines, which leads to reacting to changes and reviewing the risks to manage contingencies. Moreover, having the stats gives us the advantage of acting proactively and avoiding the recurrence of errors.
We measure what matters to us and what is affected by our performance periodically:
* Deviation
* Tasks metrics
* QA metrics
* HR metrics
* Development metrics
* Financial metrics
After the project manager is done with math, he continues with analysis and creating action items as part of improvements in the upcoming iteration or project phase. Because we deeply realize that quality is achieved in every project execution stage, the standards are set high for every team member. This process is performed through shared ownership and delegating responsibilities so that the term 'bottleneck' is not our favorite word anymore.
## NERD
DevCom leads the process from ideation to delivery and provides ongoing support through its framework, whether a consumer-oriented app or a transformative enterprise-class solution.
And yes, we have our [custom-built agile framework](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-9148) for software development using adapted approaches, real-life practices, and day-to-day activities, the **NERD,** which stands for **Nodal Ethics of Robust Development.**
You are going to love our code of conduct:
* **S**tewardship, a humble leadership
* **T**rust within the team
* **A**daptability to inevitable changes
* **R**amp-up in pursuit of continuous improvement.
You got that right, it is a STAR, but we do not need stars in the team; we need the star team.
Think of a project as some infrastructure with Nodes connected by railways. Every Node is a set of institutions, depots, warehouses, control rooms, and other buildings required to support the operations within that infrastructure. The railways are the transitions among the Nodes.
Nodes represent the required efforts in the manner of a cohesive collection of **Methods**, **Artifacts**, and **Pointers (MAP)** to complete a set of activities.
On the one hand, it requires practical experience in using other methodologies to master NERD. On the other hand, it shapes knowledge brick by brick and creates the environment to focus on people management for value delivery.
# Business Analysis
## Purpose
The **BA division within the PMO office** applies industry standard approaches to shape the client's business needs into a clear solution vision at [the pre-sales](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5728) and/or [discovery](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4441) phases. It bridges the gap between the client and the team during project execution, helping to transform the stakeholders' needs into well-defined solution requirements and managing solution scope to bring continuous value to the client to improve project success probability.
The main goal of the BA division is to help projects succeed by increasing the team's efficiency and customer satisfaction. Thus, it provides support in the following areas:
* Support for projects with BA expertise to help [set up or improve](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7042) requirements engineering and management processes to accelerate development and build trust with clients.
* Nurture internal BA resources by [evaluating](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7162) the current knowledge and offering [mentorship](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-11601) for further development.
## BA Documentation
BA Knowledge base covers the current company's needs in the development of BA expertise, which may be divided into the following areas:
* explanation of the role of BA at different project phases and the value he brings to the project;
* evaluation of the existing projects in terms of establishment and following of the BA best practices;
* evaluation of people performing BA tasks at the projects to determine the current knowledge of BA industry standard procedures and tools;
* training and mentoring of employees who perform BA role at their projects or want to transfer to BA position in future.
Besides, the BA Documentation section provides templates for BA artifacts, which may be used in projects to cover different needs. Nevertheless, the requirements and requirements management procedures do not have to be documented very formally to follow Agile philosophy; the BA documentation at the projects has many benefits:
* **Requirements approval** \- it is easier to get approval on requirements written in a certain format, which is commonly understood and accepted, thus having less background for ambiguity.
* **Scope management** \- define solution scope, ex. in the form of a Product roadmap, helps to guide the development team in the right direction and set more realistic expectations in terms of delivery.
* **Knowledge transfer** - as the project team grows, the need to transfer project and product knowledge grows as well, so well-documented BA information helps save time for onboarding new team members. In addition, a developed product knowledge base is essential when the Product is already in support, and the end users need to know the business logic and system rules.
* **Reducing uncertainty** - written requirements are easier to analyze, understand and discuss.
* **Increase quality** \- written requirements are easier to verify and validate to make sure all stakeholders have a common understanding of what's needed and approve it. Also, well-documented requirements drastically increase the quality of software testing.
One may explore BA documentation by following the steps:
1. Learn what BA does during all project stages and define one's role in the project through [BA Activities Roadmap](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-9927).
2. Check one's current level of knowledge to see the opportunities for further improvement using [BA Self-Assessment Form.](https://docs.google.com/forms/d/1EtotOFC2rwQp46oLhp7pPuOy2hssFupl9Ay-wRpz72I/edit)
3. Check out materials for self-education within [BA Training Program](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-9221).
4. Explore [BA guidelines and templates](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-6525) to support your project with needed BA expertise.
# Our Plans Tomorrow
## Vision and Domains
Periodical confirmation that we are heading in the right direction is the green light to managerial activities and keeping the team motivated.
_Web 3.0, marketing materials, preserve and grow_
# [DRAFT] Project Quality Areas Checklist
# Guidelines
Project quality is defined at every stage and phase of a project according to best practices.
Quality is "the degree to which a set of inherent characteristics fulfill requirements".
**Quality assurance** involves auditing the quality requirements and quality control results to ensure appropriate quality standards are used. When standards are not met, or goals aren’t achieved, necessary steps and corrective actions should be employed to fix these issues.
**Quality control** is about monitoring and recording the results of quality activities to assess performance and recommend necessary changes. For this matter, the project scoresheet with KPIs comes in place.
# Areas Of Quality Checklist
Check only those implemented items and leave blank that were not applicable (N/A). **Project artifacts** should exist on a project so stakeholders can identify whether the quality item/process has been set up.
| **AREA** | **ITEM/PROCESS** | **PROJECT ARTIFACT** | **ACTION ITEM** |
| ---| ---| ---| --- |
| **Presale Analysis** | 1\. Revise and document known details and artifacts:
| 1.1. Product roadmap, [System requirements](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-11800), features list, [user stories](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7662), [use cases](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7682)
1.2. Product roadmap, [SOW](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4041), [Objectives guidelines](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3981)
1.3. Docs provided by Client, [stakeholder management](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3721)
1.4. Docs provided by Client, [user stories](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7662) | 1.
1.1.
1.2.
1.3.
1.4
|
| **Proposal** |
| 1\. [Proposal](https://docs.google.com/document/d/1ywuXn0GMNWjGAuI1DqQcGROOJKFQGKvYiCak3XxP994/edit?usp=sharing) | 1. |
| **Initiation** | 1\. Define processes and set them up:
| 1.1. [Agile Charter](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3841), [Planning guidelines](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4001)
1.2. [Agile Charter](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3841), [Communication guidelines](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7082)
1.3. [Agile Charter](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3841), custom reports
1.4. [Agile Charter](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3841), [Forecast planning](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3881), [Backlog refinement](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-11920)
1.5. [Review guidelines](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4381) and the log
1.6. [Retrospective guidelines](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5421) and the log | 1.
1.1.
1.2.
1.3.
1.4.
1.5.
1.6.
|
| | 2\. Select the right tools and templates for:
| 2.1. [Communication guidelines](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7082)
2.2. [Agile Charter](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3841), Jira, Asana
2.3. [Agile Charter](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3841), Confluence, G-Drive
2.4. [Risk guidelines](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7022)
| 2.
2.1.
2.2.
2.3.
2.4.
|
| | 3\. Identify all project stakeholders and add them to the matrix:
| 4.1. [Stakeholder management](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3721)
4.2. [Stakeholder management](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3721)
4.3. [Agile Charter](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3841), [Meetings flow](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3921), [1-to-1 meetings](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7382)
| 3.
3.1.
3.2.
3.3.
|
| | 4\. Devcom's goals (financial, strategic) are aligned with project objectives:
| 4.1. Info provided by AM, [project scoresheet](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4361)
4.2. Info provided by AM
4.3. Info provided by AM
| 4.
4.1.
4.2.
4.3.
|
| | 5\. Set up and follow the security policy:
| 5.1. [Security protocols](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-11040)
5.2. [Security protocols](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-11040)
5.3. [Security protocols](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-11040), Technical project blueprint
5.4. [Security protocols](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-11040), Technical project blueprint
5.5. [Security protocols](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-11040), Technical project blueprint, Audit reports by 3rd parties
| 5.
5.1.
5.2.
5.3.
5.4.
5.5.
|
| **Requirements** |
| 1\. [Requirements guidelines](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7062), [Objectives guidelines](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3981) | 1. |
| |
| 2\. [Vision and scope guidelines](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7102) | 2. |
| |
| 3\. [Agile Charter](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3841), [Project Charter](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4221) | 3. |
| |
| 4\. [Change management](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4241) and the log
| 4. |
| |
| 5\. [Forecast planning](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3881) | 5. |
| **Design** |
| 1\. [Project Software Architecture](https://docs.google.com/document/d/1vjs_aurK5REik5Ir2Vb_eE7xnnNHKsXDH7CIcdyOYGA/edit?usp=sharing) | 1. |
| **Development** |
| 1\. [Project Software Architecture](https://docs.google.com/document/d/1vjs_aurK5REik5Ir2Vb_eE7xnnNHKsXDH7CIcdyOYGA/edit?usp=sharing) | 1. |
| |
| 2\. Technical project blueprint | 2. |
| |
| 3\. [Branching & Merging Strategy](https://docs.google.com/document/d/1grNCNBHTaR-5wYZU39e_Pql3aC2iO-k9GTfn8bup6sg/edit?usp=sharing) | 3. |
| |
| 4\. Technical project blueprint | 4. |
| | 5\. Automate deployment processes:
| 5.1. Technical project blueprint, [DevOps support flow](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4181)
5.2. Technical project blueprint, [DevOps support flow](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4181)
5.3. Technical project blueprint, [DevOps support flow](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4181) | 5.
5.1.
5.2.
5.3. |
| |
| 6\. Test Plan | 6. |
| |
| 7\. [Requirements guidelines](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7062) | 7. |
| |
| 8\. [Project scoresheet](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4361) | 8. |
| **Testing** |
| 1\. Test plan, [QA strategy guidelines](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4201) | 1. |
| |
| 2\. Test cases template, [QA strategy guidelines](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4201) | 2. |
| |
| 3\. Test plan, [QA strategy guidelines](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4201) | 3. |
| |
| 4\. [Definition of ready](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7602), [Definition of done](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5341) | 4. |
| **Delivery** |
| 1\. Product roadmap, [Forecast planning](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3881) | 1. |
| |
| 2\. [Agile Charter](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3841), [Project closure](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7322) | 3. |
| |
| 3\. [Interim](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4381) [review](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4381) | 3. |
| **Support** |
| 1\. Support Agreement | 1. |
| |
| 2\. [Project support flow](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4161) | 2. |
| |
| 3\. [Project support flow](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4161), [Requirements guidelines](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7062) | 3. |
| |
| 4\. [Knowledge sharing guidelines](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3961) | 4. |
| |
| 5\. [Agile Charter](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3841), [Retrospective guidelines](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5421) and the log, custom plan | 5. |
| | 6\. Set up AWS Account Management
| 6.1. Support Agreement
6.2. Support Agreement
6.3. Support Agreement
6.4. Support Agreement | 6.
6.1.
6.2.
6.3.
6.4. |
| |
| 7\. Support Agreement | 7. |
| |
| 8\. Support Agreement | 8. |
| | 9\. Set up Requests/Inquiries
| 9.1. Support Agreement
9.2. Support Agreement
9.3. Support Agreement
9.4. Support Agreement
9.5. Support Agreement
9.6. Support Agreement
9.7. Support Agreement
| 9.
9.1.
9.2.
9.3.
9.4.
9.5.
9.6.
9.7.
|
The result of the checklist above produces action items for the plan of improvements. After its implementation, it is recommended to go through the checklist again.
# PM Biweekly Meetings
# One-Palm Rules
1. PMO members treat each other with respect at all times.
2. Constructive feedback is a valuable part of our success so we will not take offense and all PMO members will ensure all feedback is provided in a constructive manner.
3. All personal stuff is left aside prior to beginning any of our meetings or discussions to keep better focus.
4. We will give consideration to whoever is speaking and avoid sidebars or speaking over one another.
5. We will work collaboratively when possible and use a consensus approach when making team decisions.
# Meeting agenda
* Review Action Items from the previous meeting
* Project Scoresheet review
* challenges
* blockers
* plan deviations
* resources
* Announcements:
* ideas
* suggestions
* upcoming PM events
# 📅 MM/DD/2021 (Template)
### **Meeting commencement date & time:** every second and fourth **_Thursday_** at 12**_:00_** PM.
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
|
| | |
|
| | |
|
| | |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours prior to the meeting**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** |
| --- |
| |
| |
| |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| | | |
| | | |
| | | |
# 📅 11/25/2021
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM.
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
|
| 12/9/2021 | @Andrii Bordun |
|
| | |
|
| | |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours prior to the meeting**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| L.Kucharska | EMS | Painful movement to Jira | |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| L.Kucharska | EMS | We still cannot find DBD | |
| Liana V. | ASME | We are looking for 1 more QA (student) | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| Format of meetings | Andrii B. |
| Library of templates | Andrii B. |
| PM maturity and expertise | Andrii B. |
| Knowledge Sharing format | Andrii B. |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| That will be interesting to know what other projects are doing, why not to use previous PM notes agenda (excel file), like key tasks in progress, activities in progress, plans for future, other interesting stuff | 24.11.2021 | @Taras Vons |
| [Q&A JIRA: setup and project management](https://www.youtube.com/watch?v=smKuQtZfxp4) | | Lilia |
| | | |
| | | |
# 📅 12/9/2021
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM.
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
|
| 12/9/2021 | @Andrii Bordun |
|
| 12/17/2021 | @Andrii Bordun |
|
| | |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours prior to the meeting**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| Changes in KPI table | Andrii B. |
| | |
| | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| Projects KPIs calculation | 12/9/2021 | Oleh H. |
| | | |
| | | |
* * *
## Useless KPIs
| **KPI** | **Comment** |
| ---| --- |
| Earned Value | Obsolete |
| | |
| | |
# 📅 12/23/2021
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM.
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
|
| 12/9/2021 | @Andrii Bordun |
|
| 12/17/2021 | @Andrii Bordun |
|
| 12/23/2021 | All |
|
| 12/31/2021 | @Andrii Bordun |
|
| 12/31/2021 | @Andrii Bordun |
|
Abscense rate
Capacity index
| 12/31/2021 | @Andrii Bordun |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours prior to the meeting**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| Liliia Kucharska | EMS | There are still some issues after movement to Jira | To take more time before the movement to Jira and prepare better |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| Liliia Kucharska | EMS | React developer (4-8h task) | Developer will be borrowed from Unit 2 (Ihor K.). Alternatively - Unit 4 starting next year |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| Change **Abscense rate** into **Capacity index** | Andrii B. |
| Added Aggregated sheet with % and trend tracking | Andrii B. |
| | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| Responsibility (P1) | 1/13/2022 | @Andrii Bordun |
| | | |
| | | |
* * *
# 📅 1/13/2022
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM.
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
|
| | |
|
| | |
|
| | |
|
| | |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours prior to the meeting**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| Liliia Kucharska | EMS | DBD is needed | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| | |
| | |
| | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| [Responsibility](https://docs.google.com/presentation/d/1bMT9zf3QFREpI1ULF-ieTRLDD0whjd-7XVBx2NRapUw/edit?usp=sharing) ([recording](https://drive.google.com/file/d/1NcYn7c58RN2vUWPGRPxFZ2GvGyhc8mNS/view?usp=sharing)) | 1/13/2021 | @Andrii Bordun |
| | | |
| | | |
* * *
# 📅 1/27/2022
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM.
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
|
| 02/10/2022 | @Liana Vinichuk |
|
| 02/10/2022 | @Pavlo Stelmakh |
|
| 02/04/2022 | @Andrii Bordun |
|
| | |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours prior to the meeting**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| Pavlo Stelmakh | EMS | Strong need for knowledge sharing among team members | Implement knowledge-sharing meetings across team members/records |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| Liliia Kucharska | EMS | DBD is needed | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| Vacations | @Andrii Bordun |
| COVID-19 status | @Andrii Bordun |
| PDP process and areas | @Andrii Bordun |
| New stuff (draft of career path, responsibilities, hiring, Matrix assessment, BA section) | @Andrii Bordun |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| PMBOK 7th Ed (DevcomTalk) | 02/04/2022 | @Andrii Bordun |
| | | |
| | | |
* * *
# 📅 2/10/2022
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM.
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
|
| 02/28/2022 | @Liana Vinichuk |
|
| 02/15/2022 | @Pavlo Stelmakh |
|
| 02/04/2022 | @Andrii Bordun |
|
| 02/19/2022 | ALL |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours prior to the meeting**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| Oleh H | Sharable | How you would like us to calculate the Defects fix time ratio? | Manually - not an option
Jira dashboard - needs investigation
|
| | | | |
| | | | |
| **BLOCKER** |
| | | |
|
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| Oleh H | Sharable | DEVELOPMENT KPIs are not calculated because the DevOps team is in the progress of setting up SonarQube. | Wait 🙂 |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| Tools to use for project management | @Andrii Bordun |
| | |
| | |
| | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| | | |
| | | |
| | | |
* * *
# 📅 2/24/2022
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM.
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
|
| 02/28/2022 | @Liana Vinichuk |
|
| 02/15/2022 | @Pavlo Stelmakh |
|
| 02/04/2022 | @Andrii Bordun |
|
| 02/19/2022 | ALL |
|
| 02/25/2022 | ALL |
|
| 02/19/2022 | @Andrii Bordun |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours prior to the meeting**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| Oleh H | Sharable | How you would like us to calculate the Defects fix time ratio? | Manually - not an option
Jira dashboard - needs investigation
|
| | | | |
| | | | |
| **BLOCKER** |
| | | |
|
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| Oleh H | Sharable | DEVELOPMENT KPIs are not calculated because the DevOps team is in the progress of setting up SonarQube. | Wait 🙂 |
| | | | |
| | | | |
| **RESOURCES** |
| Lillia Kucharska | EMS | Android/IOS dev is needed
(appx. 1 week task) | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| Tools to use for project management | @Andrii Bordun |
| | |
| | |
| | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| Review [video](https://www.youtube.com/watch?v=PRh80RyT74I) and provide comments | 02/24/2022 | ALL |
| | | |
| | | |
* * *
# 📅 3/3/2022
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM.
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
|
| 02/28/2022 | @Liana Vinichuk |
|
| 02/15/2022 | @Pavlo Stelmakh |
|
| 02/19/2022 | ALL |
|
| 03/18/2022 | ALL |
|
| 03/18/2022 | @Andrii Bordun |
|
| 03/31/2022 | ALL |
|
| 03/31/2022 | ALL |
|
| | |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours prior to the meeting**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | |
|
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| Lillia Kucharska | EMS | Android/IOS dev is needed
(appx. 1 week task) | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| | |
| | |
| | |
| | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| Review [video](https://www.youtube.com/watch?v=PRh80RyT74I) and provide comments | 02/24/2022 | ALL |
| | | |
| | | |
* * *
# 📅 3/17/2022
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM.
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
|
| 03/18/2022 | ALL |
|
| 03/18/2022 | @Andrii Bordun |
|
| 03/31/2022 | ALL |
|
| 03/31/2022 | ALL |
|
| 03/31/2022 | @Elina Lapka |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours prior to the meeting**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| New docs: Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-9201](https://app.clickup.com/8491693/docs/834nd-2241/834nd-9201));Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-7462](https://app.clickup.com/8491693/docs/834nd-2241/834nd-7462)); Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-7502](https://app.clickup.com/8491693/docs/834nd-2241/834nd-7502)); updated Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-3921](https://app.clickup.com/8491693/docs/834nd-2241/834nd-3921))(match with Communication plan) and Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-3981](https://app.clickup.com/8491693/docs/834nd-2241/834nd-3981))(added sample workflow); Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-3721](https://app.clickup.com/8491693/docs/834nd-2241/834nd-3721))(slight difference between small and large projects) | |
| | |
| | |
| | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| Review [video](https://www.youtube.com/watch?v=PRh80RyT74I) and provide comments | Delayed | ALL |
| | | |
| | | |
* * *
# 📅 3/31/2022
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM.
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
|
| 04/29/2022 | ALL |
|
| 04/08/2022 | ALL |
|
| 03/31/2022 | ALL |
|
| 03/31/2022 | @Elina Lapka |
|
| 04/08/2022 | @natalya.ohorodnyk |
|
| 04/08/2022 | @Andrii Bordun |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours prior to the meeting**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| Custom Framework \[for software development\] collaboration | @Andrii Bordun |
| Project Management on different types of projects | @Andrii Bordun |
| | |
| | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| Review [video](https://www.youtube.com/watch?v=PRh80RyT74I) and provide comments | Delayed | ALL |
| | | |
| | | |
* * *
# 📅 4/14/2022
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM.
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
|
| 04/29/2022 | ALL |
|
| 04/08/2022 | ALL |
|
| 04/08/2022 | @natalya.ohorodnyk |
|
| 04/08/2022 | @Andrii Bordun |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting.**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| Monthly KPIs (calculations and put the result on top of the page; calculate revenue when changes occur; ask AMs to add financial KPIs) | @Andrii Bordun |
| | |
| | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| Review [video](https://www.youtube.com/watch?v=PRh80RyT74I) and provide comments | 04/28/2022 | ALL |
| PSM I - knowledge sharing | 04/28/2022 | @Zenoviia Slipchenko |
| | | |
* * *
# 📅 4/28/2022
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM.
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
|
| 04/29/2022 | ALL |
|
| 05/13/2022 | ALL |
|
| 04/08/2022 | @natalya.ohorodnyk |
|
| 05/6/2022 | @Liana Vinichuk |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting.**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| Monthly KPIs (People agility) - collect all projects stats and compare them with the baseline | @Andrii Bordun |
| Added Team Satisfaction form to KPIs | @Andrii Bordun |
| DCM feature request (by Liana and Vitalii)
| @Liana Vinichuk |
## Team Agility
| | **AVERAGE** | **NEW BASELINE** |
| ---| ---| --- |
| **UNIT 1** |
54.86%
|
50.00%
|
| **UNIT 2** | N/A | N/A |
| **UNIT 3** |
38.78%
|
50.00%
|
| **UNIT 4** |
49.59%
|
50.00%
|
| **UNIT 5** |
29.32%
|
40.00%
|
| **Average** |
43.13%
| |
**Conclusion**: The longer people are on a team, the lower the Agility index. The more people are on a project, the lower the Agility index.
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| Review [video](https://www.youtube.com/watch?v=PRh80RyT74I) and provide comments | 04/28/2022 | ALL |
| PSM I - knowledge sharing | 04/28/2022 | @Zenoviia Slipchenko |
| | | |
* * *
# 📅 5/12/2022
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM.
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
|
| 05/17/2022 | ALL |
|
| 05/13/2022 | @Liana Vinichuk |
|
| 05/17/2022 | @Andrii Bordun |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting.**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| @Olena Khapko | DevCom Jira | necessity of Jira Time Tracking plugin | Discuss challenges and find the solution during the brainstorming |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| Share 1-to-1 meetings tips (see also Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-7382](https://app.clickup.com/8491693/docs/834nd-2241/834nd-7382))) | ALL |
| | |
| | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| Review [video](https://www.youtube.com/watch?v=Eqcdb8kpujI&t=4s) and provide comments | 05/12/2022 | ALL |
| [Valve Handbook review](https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployeeHandbook.pdf) | 05/26/2022 | ALL |
| | | |
* * *
# 📅 5/26/2022
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM.
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
|
| 05/17/2022 | ALL |
|
| 05/13/2022 | @Liana Vinichuk |
|
| 05/17/2022 | @Andrii Bordun |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting.**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| | |
| | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| Review [video](https://www.youtube.com/watch?v=MNSAolUgFYQ&t=1078s) and provide comments | 05/9/2022 | ALL |
| [Valve Handbook review](https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployeeHandbook.pdf) | 05/26/2022 | ALL |
| | | |
* * *
# 📅 6/9/2022
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM.
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
|
| 06/08/2022 | ALL |
|
| N/A | Assignee |
|
| 06/23/2022 | @Artem Pidgorodetskyi , @Zenoviia Slipchenko |
|
QA artifacts
| 06/23/2022 | ALL |
| | | |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting.**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| [Telegram channel](https://t.me/themanagerblog) for PMs | @Andrii Bordun |
| Index of project architecture | @Andrii Bordun |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| Review [video](https://www.youtube.com/watch?v=MNSAolUgFYQ&t=1078s) and provide comments | 06/09/2022 | ALL |
| [Valve Handbook review](https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployeeHandbook.pdf) | 06/23/2022 | ALL |
| Choose Topic | 06/23/2022 | @Zenoviia Slipchenko |
* * *
# 📅 6/23/2022
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM.
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
|
| 07/07/2022 | ALL |
|
| 06/23/2022 | @Artem Pidgorodetskyi , @Zenoviia Slipchenko |
|
QA artifacts
| 06/23/2022 | ALL |
| | | |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting.**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| Support Agreement (includes SLA, agreements with a Client of further product/service support). Who can assist? | @Andrii Bordun |
| | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| Effective Retrospectives | 06/23/2022 | @Zenoviia Slipchenko |
| [Valve Handbook review](https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployeeHandbook.pdf) | 07/07/2022 | ALL |
| | | |
* * *
# 📅 7/7/2022
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM.
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
|
| 07/21/2022 | ALL |
|
| 07/21/2022 | ALL |
| | | |
| | | |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting.**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| Effective Retrospective [presentation](https://docs.google.com/presentation/d/1HqsSVClTZaAuwVrWnEklR4vyfNNfOujbTuO23VQ9MdU/edit?usp=sharing) and [recording](https://drive.google.com/file/d/1TfKWp9ZFRj0eHgUZ13HzcKDgpi1lfpfn/view?usp=sharing) | @Zenoviia Slipchenko |
| | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| [Valve Handbook review](https://steamcdn-a.akamaihd.net/apps/valve/Valve_NewEmployeeHandbook.pdf) | 07/07/2022 | ALL |
| Refinement - tips | 07/21/2022 | @Zenoviia Slipchenko |
| | | |
* * *
# 📅 7/21/2022
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM.
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
|
| 07/21/2022 | ALL |
|
| 07/21/2022 | ALL |
| | | |
| | | |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting.**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| Devcom Jira accounts (monthly checkup and deactivating those older than 1 month) | @Andrii Bordun |
| | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| [Refinement - tips](https://docs.google.com/presentation/d/1XY735NEyZnYx2qclBiQrI6Kg-KFDRF1X/edit?usp=sharing&ouid=112040268533485302076&rtpof=true&sd=true) ([Recording](https://drive.google.com/file/d/1SIrLfQWhi24UOe9JKD7uyVQSoqaoPgaC/view?usp=sharing)) |
| [Refinement - tips](https://docs.google.com/presentation/d/1XY735NEyZnYx2qclBiQrI6Kg-KFDRF1X/edit?usp=sharing&ouid=112040268533485302076&rtpof=true&sd=true) ([Recording](https://drive.google.com/file/d/1SIrLfQWhi24UOe9JKD7uyVQSoqaoPgaC/view?usp=sharing)) | 07/21/2022 | @Zenoviia Slipchenko |
| ---| ---| --- |
| | | |
* * *
# 📅 8/4/2022
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM.
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
|
| 08/18/2022 | @Andrii Bordun |
|
| | |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting.**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| Vacations | |
| | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| [PM Trends 2022](https://docs.google.com/presentation/d/1Pc-E5HfIO7PfsjskSuxOL5kO0ydFdxqgZAvCmuF7_dg/edit#slide=id.p13) | 8/3/2022 | @Andrii Bordun |
| | | |
* * *
# 📅 8/18/2022
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM.
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
|
| 08/18/2022 | @Andrii Bordun |
|
| | |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting.**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| [Communication styles](https://communicationstyles.org/the-four-communication-styles/) | @Elina Lapka |
| | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| [PM Trends 2022](https://docs.google.com/presentation/d/1Pc-E5HfIO7PfsjskSuxOL5kO0ydFdxqgZAvCmuF7_dg/edit#slide=id.p13) ([Recording](https://drive.google.com/file/d/122TYXle7zvpSvuyjiseftIrq-DWUNtbr/view?usp=sharing)) | 8/3/2022 | @Andrii Bordun |
| | | |
* * *
| Communication styles - (Recording) | 08/18/2022 | @Elina Lapka |
| ---| ---| --- |
| Communication styles - ([Materials](https://drive.google.com/drive/folders/1OjRWlHYFPhrjHLDI4oC-JIb5WZNsZE1F?usp=sharing)) | 08/18/2022 | @Elina Lapka |
* * *
# 📅 9/1/2022
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM.
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
|
| 08/18/2022 | @Andrii Bordun |
|
| | |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting.**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| Create Engaging Documentation Using Information Mapping | @Elina Lapka |
| | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| | | |
| | | |
* * *
# 📅 9/15/2022
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM.
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
|
| 09/29/2022 | @Andrii Bordun |
|
| 09/29/2022 | ALL |
| | | |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting.**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| [PMI UKRAINE CONNECT](https://connect2022.pmiukraine.org/#contact-form) (10/01/2022, 6:00 pm) | PMI |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| Workshop | 09/29/2022 | @Andrii Bordun |
| | | |
* * *
# 📅 9/29/2022
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM.
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
|
| 09/29/2022 | @Andrii Bordun |
|
| 09/29/2022 | ALL |
| | | |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting.**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | KPI Team Satisfaction | Enrich the questionnaire with more specific questions | Add a question: Are you motivated? Instead of 'Do you have fun?' |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| [PMI UKRAINE CONNECT](https://connect2022.pmiukraine.org/#contact-form) (10/01/2022, 9:00 AM) | PMI |
| Fill in the attributes in Jira issues (Epic, components, custom fields) for your projects | @Andrii Bordun |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| [Workshop](https://docs.google.com/spreadsheets/d/1sW6tsEbgiGDVpQ_vl4QHh8zce6Ij1zw4VThLApGWTek/edit#gid=1747319413) | 09/29/2022 | @Andrii Bordun |
| | | |
* * *
# 📅 10/13/2022
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM.
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
|
| 10/27/2022 | @Andrii Bordun |
| | | |
| | | |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting.**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| [Workshop reflection](https://docs.google.com/spreadsheets/d/1sW6tsEbgiGDVpQ_vl4QHh8zce6Ij1zw4VThLApGWTek/edit#gid=1747319413) | @Andrii Bordun |
| [PMI video recordings.](https://vimeo.com/showcase/pmuaconnect2022) Pass: #standwithukraine2022 | @Andrii Bordun |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| Motivation | 10/27/2022 | @Pavlo Stelmakh |
| | | |
* * *
# 📅 10/27/2022
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM.
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
| Risk management
| 10/27/2022 | @Andrii Bordun |
| | | |
| | | |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting.**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| [Co-working spaces in Ukraine](https://dou.ua/lenta/articles/coworking-with-starlink/?from=nl&utm_source=newsletter&utm_medium=email&utm_campaign=26102022) | @Andrii Bordun |
| [Co-working spaces in Lviv](https://coworkingspaces.me/lviv-ukraine/) | @Olena Ishchenko |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| [Motivation](https://docs.google.com/presentation/d/1RhkC3wgbzX83A-osO_DGXuPqdCL-JuiOPQEZG9V88Bg/edit#slide=id.g166af2e3688_0_319) ([recording](https://drive.google.com/file/d/1HGf0SyL1T50W2wdDTcCIL2On3AJEl_Oi/view?usp=sharing)) | 10/27/2022 | @Pavlo Stelmakh |
| | | |
* * *
# 📅 11/10/2022
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM.
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
| Risk management
| 11/24/2022 | @Andrii Bordun |
| | | |
| | | |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting.**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| [Jira Product: Discovery](https://docs.google.com/presentation/d/1stKCmLynjpY8tpQWK3iERjviIJyK1l18LApK06JhZzk/edit#slide=id.g17b6177525a_0_14) | @Andrii Bordun |
| | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| [List of upcoming IT events](https://www.facebook.com/groups/lvivitevents/) | On-going | @Andrii Bordun |
| | | |
* * *
# 📅 11/24/2022
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM.
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
| Risk management
| 12/1/2022 | @Andrii Bordun |
| | | |
| | | |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting.**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| Would You Rather... - [workshop review](https://lucid.app/lucidchart/7ad1cadc-19fa-4540-9806-5fe6266f3286/edit?viewport_loc=632%2C-805%2C2970%2C1437%2C0_0&invitationId=inv_4e734156-169b-4be4-ae4e-6fbfa063dc2a) | @Andrii Bordun |
| Annual project audit preview (Sharable sample) | @Andrii Bordun |
| Secrets Of Power Negotiating ([Book](https://drive.google.com/file/d/1Ok4YmnHf93VWQZwE2lzZTLHA1LrikXOR/view?usp=share_link)) | @Andrii Bordun |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| Workshop: Would you rather... | 11/24/2022 | @Andrii Bordun |
| | | |
* * *
# 📅 12/08/2022
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM.
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
| Risk management
| 12/22/2022 | @Andrii Bordun |
| |
|
| 12/22/2022 | ALL |
| | | |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting.**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| | |
| | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| Effective Standups | 12/08/2022 | @Zenoviia Slipchenko |
| | | |
* * *
# 📅 12/22/2022
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM.
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
| Risk management
| 12/22/2022 | @Andrii Bordun |
| |
|
| 12/23/2022 | ALL |
| | | |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting.**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| | |
| | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| [Effective stand-ups](https://docs.google.com/presentation/d/1y54dUxU_GfWjbhg2A3Ndk3z_mfou_GytBL0SZHovX9U/edit?usp=sharing) ([recording](https://drive.google.com/file/d/13rY2gQxheivkmnJLeZyAKD6BhJgbqif2/view?usp=share_link)) | 12/08/2022 | @Zenoviia Slipchenko |
| [Secrets of Power Negotiating](https://drive.google.com/file/d/1Ok4YmnHf93VWQZwE2lzZTLHA1LrikXOR/view?usp=share_link) (1-6 Chapters) | 12/22/2022 | ALL |
* * *
# 2023 Meetings Summary
# 📅 01/05/2023
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
| Risk management
| 01/19/2023 | @Andrii Bordun |
| |
|
| 01/19/2023 | ALL |
| | | |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| | |
| | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| Non-functional requirements | 01/05/2023 | ALL |
| | | |
* * *
# 📅 01/19/2023
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
| Risk management
| 01/19/2023 | @Andrii Bordun |
| |
|
| 01/19/2023 | ALL |
| | | |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| | |
| | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| | | |
| [Secrets of Power Negotiating](https://drive.google.com/file/d/1Ok4YmnHf93VWQZwE2lzZTLHA1LrikXOR/view?usp=share_link) (1-6 [Chapters](https://docs.google.com/presentation/d/1akGg_NUhaSUkYN8qwb8GUvayy8RKUqzgT4xHLycCPLk/edit?usp=sharing)) | 01/19/2023 | ALL |
* * *
# 📅 02/02/2023
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
| Risk management
| 01/19/2023 | @Andrii Bordun |
| |
|
| 01/19/2023 | ALL |
| | | |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| | |
| | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| [Sprint Planning Practical Skills](https://docs.google.com/presentation/d/1EJM6WaxzD5o21nUfBhkT1NhzN8qWDFLeK4tD-lOCbKU/edit#slide=id.p1) ([recording](https://drive.google.com/file/d/1umQzLFWiQlUhDXhcqxq7us-UmODv8t9w/view?usp=share_link)) | | @Olena Ishchenko |
| [Secrets of Power Negotiating](https://drive.google.com/file/d/1Ok4YmnHf93VWQZwE2lzZTLHA1LrikXOR/view?usp=share_link) (7-13 [Chapters](https://docs.google.com/presentation/d/1akGg_NUhaSUkYN8qwb8GUvayy8RKUqzgT4xHLycCPLk/edit?usp=sharing)) | 01/19/2023 | ALL |
* * *
# 📅 02/16/2023
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
| Risk management
| 02/28/2023 | @Andrii Bordun |
| | | |
|
| 02/28/2023 | ALL |
| | | |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| Updated format for KPIs | @Andrii Bordun |
| Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-25400](https://app.clickup.com/8491693/docs/834nd-2241/834nd-25400))Implementation | @Andrii Bordun |
### **Example**
| **KPI** |
**ACTION ITEMS**
| **LEGEND** |
| ---| ---| --- |
| **VELOCITY** | **1) Implement RCA (in formal (written) form)**
2) Review tickets descriptions at least once a week
_3) Set up visual dependencies in Jira_
New
1) - | **Bold** \- completed items
Regular - in progress
_Italic - can't/_won't do items |
| **USER STORIES / TASKS** | \- | |
| **...** | ... | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| [Secrets of Power Negotiating](https://drive.google.com/file/d/1Ok4YmnHf93VWQZwE2lzZTLHA1LrikXOR/view?usp=share_link) (7-13 [Chapters](https://docs.google.com/presentation/d/1akGg_NUhaSUkYN8qwb8GUvayy8RKUqzgT4xHLycCPLk/edit?usp=sharing)) | 02/14/2023 | ALL |
* * *
# 📅 03/02/2023
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
| Risk management
| 03/15/2023 | @Andrii Bordun |
| | | |
|
| 03/28/2023 | ALL |
| | | |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-25400](https://app.clickup.com/8491693/docs/834nd-2241/834nd-25400))Implementation | @Andrii Bordun |
### **Example**
| **KPI** |
**ACTION ITEMS**
| **LEGEND** |
| ---| ---| --- |
| **VELOCITY** | **1) Implement RCA (in formal (written) form)**
2) Review tickets descriptions at least once a week
_3) Set up visual dependencies in Jira_
New
1) - | **Bold** \- completed items
Regular - in progress
_Italic - can't/_won't do items |
| **USER STORIES / TASKS** | \- | |
| **...** | ... | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| [Secrets of Power Negotiating](https://drive.google.com/file/d/1Ok4YmnHf93VWQZwE2lzZTLHA1LrikXOR/view?usp=share_link) (14-18 [Chapters](https://docs.google.com/presentation/d/1akGg_NUhaSUkYN8qwb8GUvayy8RKUqzgT4xHLycCPLk/edit?usp=sharing)) | 03/02/2023 | ALL |
* * *
# 📅 03/16/2023
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
| Risk management
| 03/15/2023 | @Andrii Bordun |
| | | |
|
| 03/28/2023 | ALL |
| | | |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-25400](https://app.clickup.com/8491693/docs/834nd-2241/834nd-25400))Implementation | @Andrii Bordun |
### **Example**
| **KPI** |
**ACTION ITEMS**
| **LEGEND** |
| ---| ---| --- |
| **VELOCITY** | **1) Implement RCA (in formal (written) form)**
2) Review tickets descriptions at least once a week
_3) Set up visual dependencies in Jira_
New
1) - | **Bold** \- completed items
Regular - in progress
_Italic - can't/_won't do items |
| **USER STORIES / TASKS** | \- | |
| **...** | ... | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| Development KPIs - calculation approach | 03/16/2023 | @Andrii Bordun |
* * *
# 📅 03/30/2023
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
| Risk management
| 04/28/2023 | @Andrii Bordun |
| | | |
|
| 04/28/2023 | ALL |
|
| 05/26/2023 | ALL |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-25400](https://app.clickup.com/8491693/docs/834nd-2241/834nd-25400))Implementation | @Andrii Bordun |
### **Example**
| **KPI** |
**ACTION ITEMS**
| **LEGEND** |
| ---| ---| --- |
| **VELOCITY** | **1) Implement RCA (in formal (written) form)**
2) Review tickets descriptions at least once a week
_3) Set up visual dependencies in Jira_
New
1) - | **Bold** \- completed items
Regular - in progress
_Italic - can't/_won't do items |
| **USER STORIES / TASKS** | \- | |
| **...** | ... | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| | | |
* * *
# 📅 04/13/2023
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
| Risk management
| 04/28/2023 | @Andrii Bordun |
| | | |
|
| 04/28/2023 | ALL |
|
| 05/26/2023 | ALL |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-25400](https://app.clickup.com/8491693/docs/834nd-2241/834nd-25400))Implementation | @Andrii Bordun |
### **Example**
| **KPI** |
**ACTION ITEMS**
| **LEGEND** |
| ---| ---| --- |
| **VELOCITY** | **1) Implement RCA (in formal (written) form)**
2) Review tickets descriptions at least once a week
_3) Set up visual dependencies in Jira_
New
1) - | **Bold** \- completed items
Regular - in progress
_Italic - can't/_won't do items |
| **USER STORIES / TASKS** | \- | |
| **...** | ... | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| Advanced Roadmap | 13.04.2023 | Liliia Kucharska |
* * *
# 📅 05/11/2023
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
| Risk management
| 05/26/2023 | @Andrii Bordun |
| | | |
|
| 05/26/2023 | ALL |
|
| 05/26/2023 | ALL |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-25400](https://app.clickup.com/8491693/docs/834nd-2241/834nd-25400))Implementation | @Andrii Bordun |
### **Example**
| **KPI** |
**ACTION ITEMS**
| **LEGEND** |
| ---| ---| --- |
| **VELOCITY** | **1) Implement RCA (in formal (written) form)**
2) Review tickets descriptions at least once a week
_3) Set up visual dependencies in Jira_
New
1) - | **Bold** \- completed items
Regular - in progress
_Italic - can't/_won't do items |
| **USER STORIES / TASKS** | \- | |
| **...** | ... | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| Project Support | 05/11/2023 | @Andrii Bordun |
* * *
# 📅 05/25/2023
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
| Risk management
| 05/26/2023 | @Andrii Bordun |
| | | |
|
| 05/26/2023 | ALL |
|
| 05/26/2023 | ALL |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-25400](https://app.clickup.com/8491693/docs/834nd-2241/834nd-25400))Implementation | @Andrii Bordun |
### **Example**
| **KPI** |
**ACTION ITEMS**
| **LEGEND** |
| ---| ---| --- |
| **VELOCITY** | **1) Implement RCA (in formal (written) form)**
2) Review tickets descriptions at least once a week
_3) Set up visual dependencies in Jira_
New
1) - | **Bold** \- completed items
Regular - in progress
_Italic - can't/_won't do items |
| **USER STORIES / TASKS** | \- | |
| **...** | ... | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| Project Support | 05/25/2023 | ALL |
* * *
# 📅 06/8/2023
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
| Risk management
| 06/25/2023 | @Andrii Bordun |
| | | |
|
| 06/25/2023 | ALL |
|
| 06/25/2023 | ALL |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-25400](https://app.clickup.com/8491693/docs/834nd-2241/834nd-25400))Implementation | @Andrii Bordun |
### **Example**
| **KPI** |
**ACTION ITEMS**
| **LEGEND** |
| ---| ---| --- |
| **VELOCITY** | **1) Implement RCA (in formal (written) form)**
2) Review tickets descriptions at least once a week
_3) Set up visual dependencies in Jira_
New
1) - | **Bold** \- completed items
Regular - in progress
_Italic - can't/_won't do items |
| **USER STORIES / TASKS** | \- | |
| **...** | ... | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| [Project Fail cases (lessons learned)](https://docs.google.com/presentation/d/1Uflq3d1AZZzmJzuAE_JExROGcYT0snNtg9d1WamML6g/edit?usp=sharing) | | ALL |
* * *
# 📅 06/22/2023
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
| Risk management
| 06/25/2023 | @Andrii Bordun |
| | | |
|
| 06/25/2023 | ALL |
|
| 06/25/2023 | ALL |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-25400](https://app.clickup.com/8491693/docs/834nd-2241/834nd-25400))Implementation | @Andrii Bordun |
### **Example**
| **KPI** |
**ACTION ITEMS**
| **LEGEND** |
| ---| ---| --- |
| **VELOCITY** | **1) Implement RCA (in formal (written) form)**
2) Review tickets descriptions at least once a week
_3) Set up visual dependencies in Jira_
New
1) - | **Bold** \- completed items
Regular - in progress
_Italic - can't/_won't do items |
| **USER STORIES / TASKS** | \- | |
| **...** | ... | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| [Project Fail cases (lessons learned)](https://docs.google.com/presentation/d/1Uflq3d1AZZzmJzuAE_JExROGcYT0snNtg9d1WamML6g/edit?usp=sharing) | | ALL |
* * *
# 📅 07/06/2023
### Meeting **commencement date & time:** every second and fourth _Thursday_ at 12**_:00_** PM
* * *
* **Meeting structure**
* **🎬Review Action Items from the previous meeting**
* **🧮Projects Scoresheet review**
* challenges
* blockers
* plan deviations
* resources
* **📢Announcements**
* ideas
* suggestions
* upcoming PM events
* * *
## **Action Items**
| **ACTION ITEMS & DELIVERABLES** | **DUE DATE** | **ASSIGNEE** |
| ---| ---| --- |
| Risk management
| 06/25/2023 | @Andrii Bordun |
| | | |
|
| 06/25/2023 | ALL |
|
| 06/25/2023 | ALL |
* * *
## Projects Scoresheet Review
**To be filled in 4 hours before the meeting**
| **REPORTER** | **PROJECT** | **DESCRIPTION** | **OFFERED SOLUTION** |
| ---| ---| ---| --- |
| **CHALLENGES** |
| | | | |
| | | | |
| | | | |
| **BLOCKER** |
| | | | |
| | | | |
| | | | |
| **PLAN DEVIATIONS** |
| | | | |
| | | | |
| | | | |
| **RESOURCES** |
| | | | |
| | | | |
| | | | |
* * *
## Announcements
| **IDEAS / SUGGESTIONS / EVENTS** | **REPORTER** |
| ---| --- |
| Private ([https://app.clickup.com/8491693/docs/834nd-2241/834nd-25400](https://app.clickup.com/8491693/docs/834nd-2241/834nd-25400))Implementation | @Andrii Bordun |
### **Example**
| **KPI** |
**ACTION ITEMS**
| **LEGEND** |
| ---| ---| --- |
| **VELOCITY** | **1) Implement RCA (in formal (written) form)**
2) Review tickets descriptions at least once a week
_3) Set up visual dependencies in Jira_
New
1) - | **Bold** \- completed items
Regular - in progress
_Italic - can't/_won't do items |
| **USER STORIES / TASKS** | \- | |
| **...** | ... | |
* * *
## Knowledge Sharing
| **IDEA / TOPIC** | **DATE** | **REPORTER/ASSIGNEE** |
| ---| ---| --- |
| [Project Fail cases (lessons learned)](https://docs.google.com/presentation/d/1Uflq3d1AZZzmJzuAE_JExROGcYT0snNtg9d1WamML6g/edit?usp=sharing) | | ALL |
* * *
# [DRAFT] Maturity stages
Motivation:
* Each project must go through each stage correctly in order to have quality and stable product (project).
* Projects have different needs depending on what stage in its development it exists
* Existing projects may have skipped some steps that are causing issues now
Goal:
* define project stages in order to be able to plan or assess projects against some standard
* based on the assessment - define steps to fill the gaps
* this will bring each project to expected level of quality
Stages
1. Stage 1 - "pre-proposal"
1. Someone has an idea
2. This could be a brand new product, app, business idea, change to existing system, etc.
3. This idea us usually formed in a head of what we would call "project sponsor" or "product owner"
4. This idea may exist in verbal, sound, video, text formats
# Policies and Templates
# BA responsibilities & Evaluation
# BA Responsibilities
The business analyst is the individual who has the primary responsibility to elicit, analyze, document, and validate the needs of the project stakeholders. He/she bridges the ‘understanding gap’ between the business and technology to ensure the business need is defined, and the solution brings value.
### .png)
The main tasks shared between different levels of BAs are the following:
* **Plan requirements approach** \- define the process of requirements lifecycle management (from elicitation to retirement).
* **Define requirements** on different levels: business, stakeholder, solution, and transition.
* **Collaborate with stakeholders** \- identify project stakeholders, and define the communication and engagement approach with each.
* **Elicit, analyze and document requirements** \- help stakeholders to articulate their needs, analyze the gathered information and add needed details (additional questions or acceptance criteria, or visual representation in the form of diagrams, wireframes). It also includes documenting the collected data to the appropriate level of detail (not too little and not too much) based on the selected requirements management approach.
* **Data Security**
Make sure you consider the requirements for regulatory compliance if any of the following rules apply to your customer: handling PII data, COPPA Compliance, HIPAA Compliance, PCI DSS Compliance, and SOC 2 Compliance. See this [page](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-10000) for more details.
* **Communicate requirements** \- the central part of the daily routine of each BA. Ongoing collaboration with a team and a customer to help understand and validate requirements (including presenting visual models (diagrams, wireframes) of the requirements).
* **Facilitate requirements prioritization** \- collaborate with different stakeholders to ensure that requirements are prioritized based on the business value, taking into account dependencies and constraints (technical, resources).
* **Gather and analyze solution feedback** - BA participates in demos, UAT, or other solution feedback sessions to ensure the customer gets the expected outcome and all possible improvements are considered for the subsequent project phases, if any.
A business analyst is a role so BA activities may be performed by PM, AM, or Tech Lead. The type of activity differs depending on the seniority level and the project specifics - it may be narrowed to just requirements specification for a particular system module or may require conducting [market analysis](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-29847), drafting a product roadmap, and facilitating workshops with clients.
## Difference between levels of seniority
The main difference between BA seniority levels is the level of authority performing each task, experience, and requirements they work with.
**BA Student** \- 1+ years experience in IT. Has general awareness of the BA role and the main tasks. Works with existing plans and approaches under supervision.
**Junior BA** \- 1-2 years of relevant experience, performs the main tasks under supervision. Knowledge of essential tools and approaches (see BA levels & responsibilities). He/she can work with separate stakeholders and solution requirements.
**Middle BA** \- 2+ years of relevant experience, performs the main tasks without supervision. He/she uses various BA tools and techniques, including visual models (diagrams, wireframes, matrices), works with particular solution features, and defines business requirements. On top of that, he/she manages communication with stakeholders on different levels and works with [presale](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5728) activities.
**Senior BA** \- 3-4+ years of relevant experience, defines the approach for BA tasks, mentors other BAs. Also, he/she can manage possible requirements conflicts and their escalation; work with the overall solution, not just particular features. He/she can lead presale activities.
## Requirements Types according to the International Institute of Business Analysis (IIBA)
.png)
# **BA Performance Matrix**
[https://docs.google.com/spreadsheets/d/1J6\_8PMXfxFNT7TdVWWXDZu71bEBINQ8msx5jEFOIrC4/edit?usp=sharing](https://docs.google.com/spreadsheets/d/1J6_8PMXfxFNT7TdVWWXDZu71bEBINQ8msx5jEFOIrC4/edit?usp=sharing)
# BA activities roadmap
The aim of this article is to get an overview of BA activities in the pre-project phase and during project implementation, and to provide a list of useful techniques and recommendations to support those activities.
The tasks of the BA may differ depending on how early he/she was involved in the project. And this roadmap helps to understand which activities were performed before you got to the project. However, it may happen that they were missed out, so you can cover this gap.
# **PROJECT INITIATION**
Project initiation is the first step in starting a new project. During the project initiation phase, you establish why you're doing the project and what business value it will deliver
## 1\. Define Business **needs** and success criteria
Capture the business need and distinguish whether the need is a problem to solve or an opportunity to seize. A business need may be identified at many different levels of the enterprise:
• From the top-down: a strategic goal that needs to be achieved.
• From the bottom-up: a problem with the current state of a process, function, or system.
• From middle management: a manager needs additional information to make sound decisions or must perform additional functions to meet business objectives.
• From external drivers: customer demand or business competition in the marketplace.
Help the customer define goals, expected project outcomes, expected benefits, and project acceptance criteria.
This information may be captured in the [Vision and Scope](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7102) document.
## 2\. Define stakeholders
Stakeholders are all groups, which have a relation to the changes in our system. In other words, this is anyone who’s involved in the project at any point along the way and whose input can impact your results.
The project stakeholders might have already been identified by AM and/or PM. However, BA might expand this list using the techniques defined below.
The list of potential stakeholders includes, but is not limited to:
* * End Users
* Subject Matter Experts (SME)
* Project Sponsor
* State regulators
* BA
* Tester
* PM
* Support
#### Techniques to analyze stakeholders
* * * [Onion diagram](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-12060)
* [Power/Influence Grid](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-12041)
* * * [Stakeholder register](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7482)
* [RACI matrix](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7522)
## 3\. Define the future solution
.png)
### 3.1. Define the current state
This task’s main focus is to understand why a change is needed and produce the current state description and a set of business requirements.
#### **Current state analysis techniques**
**Document Analysis:** analyze any existing documentation about the current state, including (but not limited to) documents created during the implementation of a solution (if we're analyzing the legacy solution to be replaced or enhanced), training manuals, issue reports, competitor information, published industry benchmarks, published technology trends, and performance metrics.
**Interviews:** facilitate dialogue with stakeholders to understand the current state and any needs.
**Workshops:** engage stakeholders to collaboratively describe the current state and their needs.
**SWOT Analysis:** evaluate the strengths, weaknesses, opportunities, and threats to the current state enterprise.
#### **Modeling**
**Process Modelling:** describe how work occurs within the current solution.
* [Flowchart](https://creately.com/blog/diagrams/flowchart-guide-flowchart-tutorial/)
* [BPMN](https://drive.google.com/drive/folders/1ZjGq4GLqhuNdiJ66koNCvSWszgdZsDCc)
**Scope Modelling:** define the boundaries on the current state description.
* [Context diagram](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-8688)
### 3.2. Define the future state
It may include any context about the proposed future state. It describes the new, removed, or modified components of the enterprise, its processes or a solution, or its components.
Changes might relate to existing components of an organization, such as changing a step in a process or removing a feature from an existing application, or replacing the legacy system. Change may be needed to any component of the enterprise, including (but not limited to):
* * business processes
* functions
* lines of business
* organization structures
* staff competencies
* knowledge and skills
* desktop tools
* data and information
* application systems
* technology infrastructure
#### **Future state analysis techniques**
**Brainstorming:** used to collaboratively come up with ideas for the future state.
**Business Cases**: used to capture the desired outcomes of the change initiative.
**Interviews:** used to talk to stakeholders to understand their desired future state, which needs they want to address, and what desired business objectives they want to meet.
**Workshops:** used to work with stakeholders to collaboratively describe the future state.
**Mind Mapping:** used to develop ideas for the future state and understand relationships between them.
**Prototyping:** used to model future state options and could also help determine potential value.
**Scope Modelling:** used to define the boundaries of the enterprise in the future state.
**SWOT Analysis:** used to evaluate the strengths, weaknesses, opportunities, and threats that may be exploited or mitigated by the future state
#### **Modeling**
**Data Flow Diagrams:** used to visualize data flow requirements
**Data Dictionary:** used to record details about the data involved in the change. Details may include definitions, relationships with other data, origin, format, and usage.
**Functional Decomposition:** used to break down complex systems within the future state for better understanding and to model requirements in order to identify constituent parts of an overall complex business function.
**Process Modelling:** used to show the steps or activities that are performed in the organization, or that must be performed to meet the desired change.
* [Flowchart](https://creately.com/blog/diagrams/flowchart-guide-flowchart-tutorial/)
* [BPMN](https://drive.google.com/drive/folders/1ZjGq4GLqhuNdiJ66koNCvSWszgdZsDCc)
## **3.3. Define solution-related risks**
The purpose of Assess Risks task is to understand the undesirable consequences of internal and external forces on the business during a transition to, or once in, the future state.
An understanding of the potential impact of those forces can be used to make a recommendation about a course of action.
Assessing risks includes analyzing and managing them. Risks might be related to the current state, a desired future state, a change itself, a change strategy, or any tasks being performed by the enterprise. The risks are analyzed for the:
* possible consequences if the risk occurs
* impact of those consequences
* likelihood of the risk
* the potential time frame when the risk might occur
See the [Risk management](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7022) section for more details and the Risk register Template.
#### Techniques to identify risks
**Brainstorming:** used to collaboratively identify potential risks for assessment.
**Interviews:** used to understand what stakeholders think might be risks and the various factors of those risks.
**Workshops:** used to understand what stakeholders think might be risks and the various factors of those risks.
**Mind Mapping**: used to identify and categorize potential risks and understand their relationships.
**Lessons Learned**: used as a foundation of past issues that might be risks
## **3.4. Define change strategy**
The task of strategy analysis is to define future actions to satisfy the need for an enterprise and identify the activities that are defined by those needs and solutions, as well. By performing strategy analysis, business analysts define the context of requirements and designs of certain changes.
When defining the change strategy, the business analysts employ a gap analysis between current and future states, decide on the options for the future state, and provide stakeholders with recommendations on the approach that will bring the highest value while reaching the future state.
The primary inputs for defining the change strategy are the current state description, future state description, risk analysis results, and stakeholder engagement approach. the outputs of this task are the **change strategy and solution scope.**
This strategy may be specified as a Product Vision in the [Vision and Scope](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7102) document, and additionally presented to the client as a [Proposal](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7122?block=block-0509e2c3-9c27-427b-b7e0-9b268e99d912) (as a result of Pre-sales).
# PROJECT PLANNING
The Planning Phase is critical to a project’s success. A well-thought-out project plan will provide the project team with a clear direction and understanding of their contributions to the success of the project.
## 1\. Plan Business Analysis Approach
Outlining business analysis deliverables, communication approaches with stakeholders, requirements management approach, and effort estimations.
To support these activities, you may use the following artifacts:
* [Communication plan](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7082) - to establish clear communication rules between project stakeholders. Such a plan may be also prepared by a PM, so BA will use it as a guide for communication processes, and update if needed.
* [Requirements management plan](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7062) - to ensure the requirements will be properly specified, communicated, and managed during their whole lifecycle. Please consider specifying the following sections:
* [Requirements format](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7642)
* Requirements [traceability](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-9927?block=block-9d3c222a-a0f8-4539-abc0-a3f2e34f5413)
* [Prioritization](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-11920?block=block-cd982c3f-c6d5-4624-8aee-f839e9695b4a)
* [Estimation](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4121)
* [Definition of Ready](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7602)
* [Change Management](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7702)
* [Definition of Done](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3941)
* [Acceptance](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7942)
Agreement with stakeholders on the ground rules is crucial for this stage, we need to get buy-in from a customer to support our requirements management process.
## **2\. Prepare for elicitation**
Prepare to conduct various elicitation activities to get adequate details on the requirements. Define needed materials and tools, which will be used to perform elicitation.
Ex. you might define the needed client's documentation for document analysis, check with a client whether you'll have a possibility to have a series of interviews, or you might think of organizing a workshop. The technique you use depends on many factors, among which the size of the project, the willingness of the client to contribute time to requirements elicitation, and the number of stakeholders.
## 3\. Decompose Solution
Decomposition involves breaking down processes, systems, functional areas, or deliverables into simpler components so that each part can be analyzed separately. Breaking down larger components into smaller parts makes it easier to estimate and track each work effort involved in implementing the solution.
**How to decompose a solution:**
* By functional modules
* By User scenarios
#### Techniques and tools
* * [User flow diagram](https://creately.com/blog/diagrams/user-flow-diagram/)
* [Use case diagram](https://online.visual-paradigm.com/diagrams/tutorials/use-case-diagram-tutorial/)
* [Tree diagram](https://www.lucidchart.com/pages/templates/functional-decomposition-example)
As a result, you might create epics in Jira or other high-level tasks in other task management systems (ex. Azure) to represent the decomposed elements.
For decomposition using User scenarios, you might use the Story mapping technique, which enables to decomposing of a solution by User Activities.
A workshop might be a good technique to use for User Story mapping to take feedback from stakeholders regarding possible User tasks.
**See example:**
Having a good requirements structure and obvious relations between requirements helps to support [requirements traceability](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-9927?block=block-f5b60337-cda7-45d2-b7ae-72cb67b04824).
# PROJECT EXECUTION PHASE
Project Execution is the phase in the project life cycle when the work is performed, and everything in the project plan is put into action.
## **1\. Perform Elicitation**
Elicitation is the main way to identify the product requirements. By expertly asking the right questions of subject matter experts, enabling deep conversations, and recording findings, business analysts discover the true business needs to drive the project.
Elicitation encompasses all of the activities involved with discovering requirements, such as interviews, workshops, document analysis, prototyping, and others. See the [techniques](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-9927?block=block-e39653e5-a9f0-46e5-8b76-c9be340d8d23) section for more details. The key actions are:
* Identifying the product’s expected user classes and user roles.
* Understanding user tasks and goals and the business objectives with which those tasks align.
* Working with individuals who represent each user class to understand their functionality needs and their quality expectations.
The success of an elicitation technique used depends on the maturity of the analyst, developers, users, and the customer involved.
Follow three simple steps to guide the elicitation:
1. **Prepare -** prepare for each elicitation session. Define what items you want to discuss and who can help you to get the answers. Send a clear [agenda](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-15221) before a meeting, so the stakeholders are prepared for the session.
2. **Conduct** elicitation - conduct the meeting following the established agenda.
3. **Follow-up -** prepare [Meeting Notes](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7882) and send a follow-up to all interested stakeholders.
Homework - learn the business domain of the client. Check the website, and understand the key competitors. Take a look at the stakeholder's professional profiles (if available), so you know whether this person is technical or more business, so you can plan your communication approach respectively. Define decision-makers to make sure you pay attention to their suggestions and/or concerns.
#### Techniques for requirements elicitation
**Interview:** used to ask questions of stakeholders to uncover needs, identify problems, or discover opportunities.
**Workshop:** used to elicit business analysis information, including information about customers, products, work practices, and attitudes, from a group of people in a collaborative, facilitated way.
**Brainstorming:** used to generate many ideas from a group of stakeholders in a short period, and to organize and prioritize those ideas.
**Benchmarking and Market Analysis:** used as a source of business analysis information by comparing a specific process, system, product, service, or structure with some external baseline, such as a similar organization or baseline provided by an industry association. Market analysis is used to determine what customers want and what competitors provide.
**Document Analysis:** Used to review existing systems, contracts, business procedures and policies, standards, and regulations.
**Interface Analysis:** used to understand the interaction, and characteristics of that interaction, between two entities, such as two systems, two organizations, or two people or roles.
**Process Modelling:** used to elicit processes with stakeholders during elicitation activities.
**Prototyping:** used to elicit and validate stakeholders' needs through an iterative process that creates a model of requirements or designs.
**Observation:** used to gain insight about how work is currently done, possibly in different locations and in different circumstances.
## **2\. Analyze and specify elicited requirements**
Before going to the requirements analysis and specification area, let's define why would we need documentation in Agile projects. Check the list, which includes but is not limited to the following benefits:
\- Requirements approval
\- Scope management
\- Knowledge transfer
\- Reducing uncertainty
\- Increase quality
\- Justify the work done for the client
Requirements analysis and specification involve refining requirements elicitation results into different requirements levels: business requirements and rules, user requirements, system requirements (functional, non-functional), and transition requirements. At this stage, we need to select the work products that are adequate for a given level of abstraction.
This activity involves reaching a more precise understanding of each requirement and representing sets of requirements in multiple ways. Following are the principal activities:
* Analyzing the information received from users to distinguish their tasks, and goals from functional requirements, quality expectations, business rules, suggested solutions, and other information
* Decomposing high-level requirements into an appropriate level of detail
* Deriving functional requirements from other requirements information
* Understanding the relative importance of quality attributes
* Allocating requirements to software components defined in the system architecture
* Negotiating implementation priorities
* Identifying gaps in requirements or unnecessary requirements as they relate to the defined scope
### **Business requirements**
Business requirements represent the top of the requirements chain. Usually, they are well understood by the customer's management but are not as transparent for the BA and the team. Business requirements are related to a specific business need.
Business opportunities, business objectives, success metrics, and a vision statement make up the business requirements.
They also may be derived from business rules.
Business rules is a policy, guideline, standard, or regulation that defines or constrains some aspect of the business.
See example:
**Business Rule:** You must be 21 or older to view the alcohol product website.
**Business Requirement:** The user shall provide a birthdate as proof of their age.
Business requirements and business rules may be aggregated in the [Vision and Scope Document.](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7102)
### **Stakeholder requirements**
Stakeholder requirements are often referred to as user needs or user requirements and describe users' goals and tasks in the system.
User requirements are usually specified as [User Stories.](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7662)
### **Solution requirements**
Requirements, which should be followed by the system to meet user needs. They are divided into functional and non-functional requirements.
**Functional requirements** - description of behavior that a system will exhibit under specific conditions.
When looking at functional requirements, we observe that they pertain to different aspects, such as, for example, a required data structure, a required order of actions, or the required reaction to some external event. We distinguish between three major aspects: structure and data, function and flow, and state and behavior.
The **structure and data aspect** focuses on requirements concerning the static structure of a system and the (persistent) data that a system must know in order to perform the required functions and deliver the required results.
You may specify this type of requirement using [Data Dictionary](https://thebadoc.com/ba-techniques/f/defining-a-data-dictionary).
The **function and flow aspect** deals with the functions that a system shall provide and the flow of control and data within and between functions for creating the required results from given inputs.
This aspect may be specified using [Data Flow diagram](https://online.visual-paradigm.com/knowledge/software-design/dfd-tutorial-yourdon-notation), [Activity diagram](https://tallyfy.com/uml-diagram/#activity-diagram), and [Sequence diagram](https://thebadoc.com/focus-group-discussion/f/sequence-diagrams-made-simple).
The **state and behavior aspect** concentrates on specifying the state-dependent behavior of a system— in particular, how a system shall react to which external event depending on the system’s current state.
This aspect may be specified using a [State-Machine diagram](https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-state-machine-diagram/).
**Non-functional** - a description of a property or characteristic that a system must exhibit or a constraint that it must respect. In other words, how well the system should perform its functions (security, performance, compatibility etc. See the full list [here](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7102?block=block-ea795500-ad7a-4955-8036-7be95c26bd2c).)
Within the quality requirements, performance requirements are of particular importance. Performance requirements deal with:
* Time (e.g., for performing a task or reacting to external events)
* Volume (e.g., required database size)
* Frequency (e.g., of computing a function or receiving stimuli from sensors)
* Throughput (e.g., data transmission or transaction rates)
* Resource consumption (e.g., CPU, storage, bandwidth, battery)
Functional/non-functional requirements may be specified as [Acceptance criteria](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7662?block=block-5fc6b20d-495f-44f0-8e9c-521a10b580d0) for relevant User Stories.
**Transition** requirements are applicable while migrating from a previous system to a new one. Those might be data migrations, user training, data conversions, organizational and business process changes, and the need to run both old and new systems in parallel for a period of time. They are differentiated from other requirements types because they are of a temporary nature, so they are not needed, once the change is complete.
Transition requirements might be captured as separate tasks in a backlog, or in the product requirements section in the project's Wiki.
You may use those [checklists](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-10181) to make sure your requirements are of good quality.
### Modeling
The aim of the modeling is to visualize the structure or behavior of the business domain or information system for its further analysis and/or improvement.
Modeling is usually used during requirements analysis to visualize business processes or user activities and interactions with a new system. During this activity new questions and insights may come up, so we can further clarify those questions with a client. Also, visual models are usually better understood than just plain text.
Unified Modeling Language (UML) is usually used to draw models, which would be understood by different stakeholders.
You may use several models to show different aspects of the system.
There are two types of UML diagrams: behavioral and structural. See some examples below:
**Behavioral**
[Activity Diagram](https://tallyfy.com/uml-diagram/#activity-diagram)
[Use Case Diagram](https://tallyfy.com/uml-diagram/#use-case-diagram)
[State Machine Diagram](https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-state-machine-diagram/)
[Sequence Diagram](https://thebadoc.com/focus-group-discussion/f/sequence-diagrams-made-simple)
**Structural**
[Class diagram](https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-class-diagram-tutorial/)
[Object diagram](https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-object-diagram/)
Usually, BAs use behavioral diagrams to depict business processes and user interactions with a system. Structural diagrams are more technical and usually used by developers to represent the structure of a system.
### Sensitive Data
Sensitive data is private information that must be securely encrypted and out of the hands of anyone who does not have the authorization to see it. Data security and information security measures should be in place to limit access to sensitive data to prevent data leaks and intrusions.
### Identifying requirements related to sensitive data protection
Make sure you take into account any possible requirements for regulatory compliance, ex. handling PII data, COPPA Compliance, HIPAA Compliance, PCI DSS Compliance, SOC 2 Compliance. For more details on those regulatory requirements, please see this [page.](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-10000)
During analyzing the future system and the related processes and flows, pay attention to the processes, which potentially relate to handling sensitive data.
For example, the **business process** might be - "Grant access to patients’ medical records in the system".
**Sensitive data** here - "Patient’s medical records, patient credentials".
The **potential tread** for this data is - spoofing - interception of data or credentials, in order to gain unauthorized access to medical record information aiming at the patient's financial or personal harm.
Spoofing and its consequences can **be prevented by**: (1) engaging undisputable user authentication characteristics, e.g. biometrics like fingerprint, face recognition etc.; (2) early notification of the concerned user; (3) ability to deactivate the process; (4) ability to withdraw the already granted access; (5) mechanisms regarding user reporting of security incidents etc. - **all these are the requirements for sensitive data protection.**
## **3\. Validate the elicited requirements**
Validation confirms that you have the correct set of requirements information that will enable developers to build a solution that satisfies the business objectives. The central activities are:
* Review the documented requirements to correct any problems before the development team accepts them.
* Develop acceptance criteria to confirm that a product based on the requirements would meet customer needs and achieve the business objectives. Iteration is a key to requirements development success. Plan for multiple cycles of exploring requirements, progressively refining high-level requirements into more precision and detail and confirming correctness with users. This activity is usually done during [Backlog refinement](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-11920).
### Prototyping
Requirements validation may be also supported by Prototyping. The power of prototyping is in visualization. Any visualization of a requirement will enable stakeholders to evaluate and clarify more details.
A prototype is a live mockup of your product. A prototype defines the structure, user flow, and navigational details (such as buttons and menus) without committing to final details, like visual design.
Prototyping can be used to identify missing requirements and unconfirmed assumptions by showing what the product looks like and how it behaves in the early stages of design.
There are two common approaches to prototyping:
1. **Throw-away** \- this prototype may be created on paper, or by using some applications (ex. Lucidchart, Balsamiq), it can be interactive or not, and its main aim is to discover and simplify requirements, but it does not form part of the final solution. Those types of prototypes are used mainly for feedback. Using multiple throwaway prototypes helps in detecting different problems and saves costs on fixing them in the future.
2. **Evolutionary or Functional** - in this approach, the prototypes are created to transform the initial requirements into a functioning solution. They are usually created with specialized prototyping tools or language (ex. Retool). Evolutionary prototyping is a much slower process than throwaway prototyping because every change is taken with great care.
It is always helpful to determine the fidelity of the prototypes in advance to save plenty of time at later stages.
The fidelity could be identified as
**Low fidelity**
* _Use_: Give insight of all the features and content for the project
* _Traits_: Sketches, black and white representation
**Mid fidelity**
* _Use_: Considering as a transitional phase that allows more flexibility, creativity, and interaction
* _Traits_: Sketch, black and white /color representation, interactions to make the navigational flow clearer
**High fidelity**
* _Use_: Almost a replica of the exact design. A pixel-perfect version of what would actually look like when complete
* _Traits_: Pixel-perfect in terms of color, margins, layout, dimensions, content, navigation, animations, etc.
## 4\. Manage requirements life-cycle
At this stage, we have requirements specified at different levels of abstraction. Further, it is essential to organize those requirements (ex. [Backlog](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7542)), so that project stakeholders have access to them, make sure the further requirements, which would be gathered during the project, will be specified in a particular format, and that the changes to the requirements will be tracked and their impact analyzed. Those rules should have been already established during the project planning phase in a [Requirements management plan](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7062), and now should be followed.
Usually, requirements are stored in the project's Wiki (ex. Confluence) or in issue tracking systems like Jira, Azzure etc. in the form of [User Stories](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7662) and [Tasks](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-11800). You may use the following [format](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5361) to store your requirements in Confluence or other Wiki.
In addition, it is essential to support requirements traceability to ensure that the delivered software fulfills all requirements and that we don't add any unnecessary requirements, which don't contribute to the business need.
### Requirements traceability
Often, simple software changes have far-reaching impacts, which involve the modification of many parts of the system. It’s hard to find all the system elements that might be affected by an updated requirement without looking into a code. Requirements trace information documents the dependencies and logical links between individual requirements and other system elements, which helps to perform impact analysis by helping you identify all the work products you might have to modify to implement a proposed requirement change.
We define the forward and backward traceability:
* **Forward traceability**: is used to check whether the project progresses in the desired direction and for the right product. It makes sure that each requirement is applied to the product and that each requirement is tested thoroughly. It maps requirements to test cases.
* **Backward or reverse traceability:** It is used to ensure whether the current product remains on the right track. The purpose behind this type of traceability is to verify that we are not expanding the scope of the project by adding code, design elements, tests or other work that is not specified in the requirements. It maps test cases to requirements.
Following are some potential benefits of implementing requirements tracing:
* Finding missing requirements - ex. business requirements that don’t trace to any user requirements, and user requirements that don’t trace to any functional requirements.
* Finding unnecessary requirements - ex. any functional requirements that don’t trace back to user or business requirements and therefore might not be needed.
* Change impact analysis - helps to make sure that you don't overlook a system element that would be affected if you add, delete, or modify a particular requirement.
* Ensuring test coverage - linking requirements to test cases helps to make sure that you don't miss requirements, which need to be tested.
#### Techniques and tools
[Requirements Traceability matrix](https://www.saviom.com/blog/requirement-traceability-matrix-and-why-is-it-important/)
You may use [Jira plugins](https://medium.com/akeo-tech/requirements-traceability-matrix-rtm-with-jira-1ac37edbf58f#:~:text=Requirements%20Traceability%20Matrix%20is%20generally,linked%20with%20the%20user%2Dstory.) to add test cases to the User Stories and create Views to see a Traceability matrix
See the Traceability Matrix example in a spreadsheet.
[https://docs.google.com/spreadsheets/d/1Nk4yf47d0fGd2d77X\_kO0urbQzfBRzX1OJuFmvlYga8/edit?usp=sharing](https://docs.google.com/spreadsheets/d/1Nk4yf47d0fGd2d77X_kO0urbQzfBRzX1OJuFmvlYga8/edit?usp=sharing)
## 5\. Evaluate the solution
When performing the [solution evaluation](https://businessanalystmentor.com/solution-evaluation/), the business analyst assesses the solution in terms of the value it brings to the organization. The solution should not be necessarily complete to perform evaluation, however, it should be usable to some extent.
Solutions can be evaluated in different phases of development: as prototypes, proofs of concepts, as pilot or beta releases, or as operational releases.
The evaluation is done through performance assessments, experiments, and tests and can be both objective and subjective.
Usually, BA analyzes the client's feedback on the implemented solution or solution component at a demo or in another relevant format. The main task here is to process the client's feedback according to the change [management procedure](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7702)
**Some sources for the feedback:**
* Demo
* User Acceptance Testing ([UAT](https://www.softwaretestinghelp.com/what-is-user-acceptance-testing-uat/)) - also known as beta or end-user testing
* Defects
* User support requests
# PROJECT CLOSURE
Project closure is performed to formally complete or close a project or contract.
BA is usually involved in the following activities:
* **Performance Measures** – If customers don’t have performance metrics related to the project readily available, the business analyst may be involved in collecting and evaluating performance measures to help determine the value and success of the project.
The success criteria defined during project initiation would be of great value here.
* **Lessons learned** – take part in lessons learned (retrospective) activities.
# Requirements Management for a Project/Phase
This article aims to get an overview of requirements management practices and documents needed for different project phases to ensure requirements are appropriately defined, specified, and implemented.
# **Project Initiation**
Project initiation is the first step in starting a new project. During the project initiation phase, you establish why you're doing the project and what business value it will deliver.
During the initiation phase, the requirements management processes focus on the following:
1. Defining the initial project requirements, business background, business needs, and goals (Solution Vision section in the [Vision and Scope](https://docs.google.com/document/d/1yMqfEtxApXiTHRlQbnlMcZo0ILFU-SXzUpxlZ4w7NWM/edit#heading=h.9e8q949h8ct2) document)
2. Identifying the stakeholders involved in the requirements management process (Project overview section in the [Vision and Scope](https://docs.google.com/document/d/1yMqfEtxApXiTHRlQbnlMcZo0ILFU-SXzUpxlZ4w7NWM/edit#heading=h.9e8q949h8ct2) Document).
3. Developing a list of high-level requirements outlining the key features and functionalities of the project (Solution Scope section in the [Vision and Scope](https://docs.google.com/document/d/1yMqfEtxApXiTHRlQbnlMcZo0ILFU-SXzUpxlZ4w7NWM/edit#heading=h.9e8q949h8ct24) document).
4. Prepare a [Communication plan](https://docs.google.com/document/d/1hevTXXKRuQ4KhWHmvn-Z52VyZkVpUiHwPuAvIOMPplU/edit#), particularly for interviews and/or workshops, to elicit detailed requirements for the Project planning phase.
5. Prepare [Requirements management plan](https://docs.google.com/document/d/176TBxNcRVFfLlbrlnp_AN0HFlx4ET9yGteXY64XXk_Q/edit#heading=h.cw08c9qbktbl) (RMP) to establish:
1. [Requirements format](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7642)
2. [Prioritization](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-11920?block=block-10b08163-b5f5-41dc-8800-93a24a5c9614)
3. [Estimation](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4121)
4. [Definition of Ready](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7602)
5. [Change Management](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7702)
6. [Definition of Done](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3941)
7. [Acceptance](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7942)
# Project Planning
During the planning phase, the requirements management processes focus on developing a detailed requirements management plan and establishing the processes and procedures that will be used to manage requirements throughout the project.
1. Create a detailed requirements document that includes acceptance criteria, use cases, and user stories.
1. This may be documented in Confluence, the knowledgebase for User Stories and Tasks in Jira.
Use Epics for major functionality/system modules, then break them down into User Stories and related tasks needed to complete relevant User Stories.
1. Verify and validate the specified requirements to ensure they correspond to the defined format (as per RMP) and meet the client's business needs.
2. Prioritize requirements based on stakeholder needs and project objectives.
3. Estimate the effort required to complete each requirement (usually, PM leads this initiative).
4. Make sure your requirements are traceable - ex. **Epics** in Jira define the **Business requirements**, which are linked to the **User stories**, which define **User Requirements**, which have **Acceptance criteria** and tasks representing **System requirements**, which are then linked to the **Test cases** to verify them.
# Project Execution Phase
Project Execution is the phase in the project life cycle when the work is performed and everything in the project plan is implemented.
1. Conducting regular reviews of requirements to ensure they are being implemented correctly.
2. Addressing any changes or issues that arise during implementation.
3. Continuously communicating with stakeholders to ensure their needs are being met.
# Project Monitoring
The goal of this phase is to monitor project progress and make any necessary adjustments to ensure project objectives are being met.
1. Conducting regular reviews of requirements to ensure they are still relevant and aligned with project objectives.
Solution Demos may be a good source of truth to ensure the implementation is on track and corresponds to the client's needs.
1. Identifying any new or changed requirements and ensuring they are properly documented and prioritized (per change management procedure defined in RMP).
2. Addressing any risks or issues that may impact the project objectives.
# Project Closure
Project closure is performed to formally complete or close a project or contract and ensure that all requirements have been met.
1. Conducting a final review of requirements to ensure all acceptance criteria are met.
2. Documenting any lessons learned related to requirement management for future projects.
3. Ensuring all stakeholders are satisfied with the project deliverables and their needs are met.
# Requirements documentation for different cases
Adapting documentation to the project context and selecting appropriate work products for documenting requirements and requirements-related information is vital.
A work product can be:
* Plain text description
* Diagram
* Software requirements specification (SRS)
* Vision and Scope document
* Any other documents describing requirements and requirements-related information
**Work products can be categorized per:**
**Purpose and size**
**Lifespan**
* * temporary (ex. sketch created during the workshop to gain a shared understanding)
* evolving (an artifact that is worked on in iterations., ex. user stories, which are complemented with acceptance criteria and new details)
* durable (baselined or released requirements; ex. SRS for a fixed-price project, or when evolving work product is base-lined.)
* others
**Abstraction levels**
**There are several typical abstraction levels:**
* Business, domain requirements
* Stakeholder/user requirements
* System requirements.
Business requirements are usually specified in Business requirements specifications, stakeholder requirements specifications, and vision documents. They precede the specification of system requirements.
### **System requirements**
**Functional requirements** can be divided into _structure and data_, _function and flow_, and _state and behavior_.
**Non-functional requirements** can be verified using ISO/IEC 25010 model. However, performance requirements are of particular importance and worth specifying if applicable. Performance requirements deal with:
* Time (ex., for performing a task or reacting to an external event)
* Volume (ex. required database size)
* Frequency (ex., of computing a function)
* Throughput (ex., data transmission or transaction rates)
* Resource consumption (ex., CPU, storage, bandwidth)
Whenever possible, measurable values should be specified or ranges (min and max).
**Constraints**
* _Technical_: given interfaces or protocols, components, or frameworks that must be used, etc.
* _Legal:_ restrictions imposed by laws, and contracts, standards, or regulations.
* _Organizational:_ constraints in terms of organizational structures, processes, or policies that must not be changed by the system.
* _Cultural:_ user habits and expectations are, to some extent, shaped by the culture the users live in. This aspect should be considered, especially in situations when users of a system and development team are rooted in different cultures.
* _Environmental:_ when specifying cyber-physical systems, environmental conditions such as temperature, humidity, radiation, or vibration may have to be considered as constraints.
* _Physical:_ when a system comprises of or interacts with physical components, the system becomes constrained by the laws of physics and the properties of materials used for the physical components.
### Template-based work products
**Phrase Templates**
A phrase template provides a structure with placeholders to fill in to get well-structured, uniform sentences that express the requirements. See examples [here.](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-11800)
There are also phrasal templates for [User stories](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7662).
**Form Templates**
Those are templates providing a form with predefined fields to be filled in. For example, [Use Cases](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7682).
**Document Templates**
Ex. [Vision and Scope](https://docs.google.com/document/d/1yMqfEtxApXiTHRlQbnlMcZo0ILFU-SXzUpxlZ4w7NWM/edit#heading=h.ws3cd3ij2ki1) document.
### Model-based work Products
Those are UML diagrams of different types.
Ex. Use case diagram, Activity diagram, BPMN, Context diagram, Sequence diagram, etc.
# BA Project Audit Model
The BA audit model analyzes BA activities at a particular project to ensure the requirements management flow is set and followed; communication with the client and the team is performed regularly and with the appropriate level of detail.
# BA Audit Areas
## Solution Strategy and Analysis
The main aim of this area is to ensure that we implement the solution which satisfies the client’s business needs in the best possible way.
## Stakeholder management
Stakeholder management activity helps to encourage stakeholders to work towards a common goal. It is crucial in case many stakeholders participate in the requirements management process.
## Information management
This area helps ensure that all stakeholders agree on the requirements flow process, including requirements sign-off; the team knows whom to refer to collect the requirements and has little or no questions once requirements are refined.
## Requirements elicitation
This activity helps to obtain information from stakeholders and confirm the results.
## Requirements specification and documentation
It helps organize requirements discovered during elicitation activities, specify and model them, validate and verify information, identify solution options that meet business needs, and estimate the potential value.
## Requirements prioritization and release planning
To ensure the essential requirements are implemented first, product requirements are planned for a few sprints to ensure continuous development.
## Change management
Ensure the changes are tracked, and their impact analyzed to avoid scope creep.
# BA Audit Process
1. AM requests a BA audit on a particular project.
2. BA schedules kick-off meeting with the project team:
1. Provides details on the audit process, its needs, and expected outcomes.
2. Schedules the following interview(s).
3. BA performs the audit:
1. Interviews the relevant project stakeholders (AM, TL, QC, PM).
2. Evaluates the areas listed in the section above.
4. As a result of the audit, BA provides recommendations on possible process improvements.
5. BA schedules a meeting to give recommendations:
1. The project team has an opportunity to ask questions regarding evaluation and agree or disagree with the recommendations.
2. As a result of the meeting, action items should be outlined with particular priorities and deadlines.
6. In 2-3 months after that meeting, a follow-up should be scheduled:
1. At this meeting, the project team reviews whether action items were fulfilled and whether they had an effect on the project performance from a BA perspective.
2. If some action items were not fulfilled, the project team defines the reasons and outlines the following action items.
# BA Audit Tool
[https://docs.google.com/spreadsheets/d/1RVyMwHDNpn4G\_hOkLaEtK9Vvc5MGB8hZTj1B-23FC\_Y/edit#gid=0](https://docs.google.com/spreadsheets/d/1RVyMwHDNpn4G_hOkLaEtK9Vvc5MGB8hZTj1B-23FC_Y/edit#gid=0)
# BA Tools and Artifacts
This section covers different BA tools, which might be useful to support BA tasks during the whole project life circle.
# Vision and Scope Document
# Vision and Scope Document Sections
The Vision and Scope document is created during the project planning or discovery phase, and other artifacts created at later stages may override the information presented here.
You may exclude some of the listed below sections, depending on the project size and its needs.
## Document Overview
This overview is aimed to help with an understanding of the purpose of the Vision and Scope document, how it is organized, and what information it contains.
This document aims to focus on the capabilities needed by the stakeholders and represent a common understanding of the project to facilitate communication among the stakeholders. It also outlines the boundaries of multiple project dimensions, including approach, deliverables, milestones, and scope, serving as an agreement among the project team, the project sponsor, and key stakeholders. The document is focused on the business audience and usually doesn't require deep knowledge of applied technology or processes.
This document does not cover the actual implementation of the project but contains just an overview of the business and technical aspects without deep-diving.
The Document Summary usually includes the core contacts ([**Stakeholder register**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7482)) and provides the definitions of all terms, acronyms, and references required to correctly interpret the document (Glossary of Terms).
## Project Overview
This section summarizes some of the business details of the project. You may include profiles of the major stakeholders and company overview to help the project team understand how the client's company positions itself, its product range, and the market segment it covers.
### Client's company overview
A concise description of the customer company to help the project team get a general understanding of the client they work with.
The following information may be included in a profile:
* Basic info like name, location, foundation year, number of employees, and annual sales.
* List of office locations and subsidiaries.
* A summary of a company's focus, history, competitive position, and corporate structure [(Organizational chart](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7082?block=block-5a4ecba7-88cd-49aa-8931-3682718f409f)).
* The product range and the market segment.
* Major future market expansion and diversification plans.
* Significant current and future challenges and opportunities faced.
### Stakeholders Register (optional)
The purpose of the stakeholder register is to document who is impacted by the project/program and their influence and impact on the project/program. It is created early in the project and updated as new stakeholders appear.
Usually, the [Stakeholder register](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7482) is created by PM or AM. However, if this artifact does not exist, you may include it in Vision and Scope and transfer it to the [Communication plan](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7082) later.
### Stakeholders profiles (optional)
Stakeholders are individuals, groups, or organizations that are actively involved in a project and are affected by its outcome or can influence its outcome.
If communication with the client is done via 1-2 stakeholders (for example, via Product Owner), stakeholder profiles may be skipped. Otherwise, this section would be useful in order to understand the attitudes and interests of different stakeholders and leverage communication accordingly.
The stakeholder profiles identify the customers for this product and other stakeholders, including their significant interests in the product. It is essential to characterize different user classes to reduce the likelihood of unexpected requirements in the future, which would be hard to adjust because of schedule or scope constraints. The profile includes the primary value or benefits they will receive from the product, their likely attitudes toward the product, major features and characteristics of interest, and any known constraints that must be accommodated.
Examples of stakeholder value include but are not limited to:
* improved productivity;
* reduced rework;
* cost savings;
* streamlined business processes;
* automation of previously manual tasks;
* ability to perform entirely new tasks or functions;
* conformance to current standards or regulations;
* improved usability or reduced frustration level compared to existing applications.
Please see an example of stakeholder profiles for the Cafeteria Ordering System from Wiegers K., 2013.
#### **Stakeholder profiles**
## Solution vision
This section provides a clear statement of the product goals and vision. This statement is assumed to capture the views of many potential stakeholders and types of users and clearly shows the business benefits of the project. It also includes a description of the business background, main business objectives and goals, and some quantifiable success criteria for the objectives. In addition, it may contain the business risks associated with the development of the solution.
### Business background
This section describes the business background to provide a context to the business needs. It also has a general description of the client’s business specifics, and the history or situation that leads to the recognition that this product should be built. As an example, this may be the description of existing business processes and operational nuances to summarize the rationale for the new product.
### Business problem and goals
One has to describe the market business opportunity identified by the company, the business problem that has to be solved, or the process targeted to be improved. It is worth mentioning that the needs of typical customers or the target market present customer problems that the new product will address.
**Factors the business analyst may consider:**
* Expected benefits from any potential solution (ex. increased market share, reduced costs, increased revenue);
* negative effects the problem causes within the organization and quantify those effects (ex., potential lost revenue, inefficiencies, unsatisfied customers, low employee motivation);
* the approximate time it takes for the problem to be resolved or to take the opportunity, and how much it would cost to do nothing;
* the primary source of the business problem.
It is crucial to define the business needs early in a project and before the scope. In addition, it would be helpful to justify why the project develops now, what will happen if we realize it later or if we don't realize it at all, and who will benefit from this project.
**Possible Business Goals that may be used to model objectives:**
* ROI (Return on Investment), Cost savings/cost reductions;
* improving customer service;
* introducing new technology;
* simplifying the workflow;
* increasing competitive advantage;
* improving operating efficiency;
* expanding or improving core competency;
* enhancing productivity;
* reducing paperwork;
* reducing manual processes;
* increasing accuracy/quality;
* customer service improvements;
* resource management improvements.
### Vision statement
It applies to new products only and summarizes the purpose and intent of the new product, and describes who the customers are, what customers need, and how those needs will be met.
One of the best ways to create the product vision is in the form of an elevator pitch (Wiegers K., 2013), so you can craft it using the following keyword template:
**For**
**Who**
**The**
**Is**
**That**
**Unlike**
**Our product**
#### Example for Cafeteria ordering system from Wiegers K., 2013
**For** _employees_
**Who** _want to order meals from the company cafeteria or from local restaurants online,_
**The** _Cafeteria Ordering System_
**Is** _an Internet-based and smartphone-enabled application_
**That** _will accept individual or group meal orders, process payments, and trigger delivery of the prepared meals to a designated location on the Process Impact campus._
**Unlike** _the current telephone and manual ordering processes, employees who use_
**the Cafeteria Ordering System** _will not have to go to the cafeteria to get their meals, which will save them time and will increase the food choices available to them._
### Solution risks
Content on this section should be created in collaboration with AM/PM and the Product Owner (if available).
Summarize the major business risks associated with developing or not developing this product. Risk categories include marketplace competition, timing issues, user acceptance, implementation issues, and possible negative impacts on the business.
Identifying and monitoring risks is an ongoing process throughout the solution development and during the stakeholder acceptance phase. Risks will be categorized and recorded in the [**_Risk registers_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7022?block=block-45d282a5-3cdd-4f81-94f2-6e38cc3063a1) to be appropriately documented. Once the risks have been identified, the business analyst should develop a risk response strategy. The choices of the response strategies can be found in the [](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7022?block=block-b54a9092-f2dd-4241-a60b-d09d4d726114)[**_Risk Management_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7022?block=block-b54a9092-f2dd-4241-a60b-d09d4d726114) guide.
### Success criteria
At the very beginning, a project organization and its vendor (Product Owner and Business Analyst) should spend some time describing the desired outcome and how success will be defined and measured after the solution/product is implemented.
#### Examples of desired outcomes include:
* Create a new capability such as a new product or service, addressing a competitive disadvantage, or creating a unique competitive advantage.
* Improve revenue by increasing sales or reducing costs.
* Increase customer satisfaction.
* Increase employee satisfaction.
* Comply with new regulations.
* Improve safety.
* Reduce time to deliver a product or service.
The following is the template with metrics type and suggested indicators to measure them. You may skip those unless it applies to your type of product.
#### Template
| **SUCCESS CRITERIA** | **DESCRIPTION** |
| ---| --- |
| _Success Criteria_ | _Describe the criteria and provide the method used to gather criteria data._ |
#### Example of Cafeteria Ordering System (Wiegers K., 2013)
| **SUCCESS CRITERIA** | **DESCRIPTION** |
| ---| --- |
| Ease of use/quantity of use | 75% of employees who used the cafeteria at least 3 times per week during Q3 2013 used the COS at least once a week within 6 months following the initial release. |
| User satisfaction | The average rating on the quarterly cafeteria satisfaction survey increases by 0.5 on a scale of 1 to 6 from the Q3 2013 rating within 3 months following the initial release and by 1.0 within 12 months. |
#### **Possible success criteria you may use:**
| **Success Criteria** | **Description** |
| ---| --- |
| Benefit(s) to the organization | List the benefits the organization should achieve once the product is developed and implemented |
| Stakeholder satisfaction | A survey can be conducted to gather feedback from stakeholders and measure their average level of satisfaction |
| Users satisfaction | A survey can be conducted to gather feedback from stakeholders and measure their average level of satisfaction |
| Number of issues recorded since implementation | # of issues reported by all user groups and recorders after implementation |
| Ease of use/quantity of use | A survey should be conducted among users to gather feedback and count the average usability level |
| The solved problem(s) project was intended to solve | List problems the project was supposed to solve. The total number of problems will be indicated as planned data. |
| Unintentional improvement/complication to processes/procedures | Maybe discovered after the implementation phase in the form of user feedback |
## Solution scope
This section describes business requirements, assumptions, and constraints that were made during the pre-sales/discovery phase and the dependencies that exist. Defining the assumptions and dependencies will help us identify and reduce the risks and clarify the constraints to the various project and product stakeholders.
The limitations include the functionalities and features that are out of scope and will not be provided by the product in future releases. Clearly stating the limitations will help the project team and the customer clarifies the product's expectations and functional and non-functional boundaries to reduce possible future conflicts between the various stakeholders.
This section explicitly lists the functionalities and features included in different releases or versions of the product. The scope of each release is developed in line with the stakeholder's objectives and priorities; it also lessens the chance of future misunderstandings between the developers and clients.
[**_Context diagrams_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-8688), and [**_feature trees_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-8708) are among the most common ways to represent scope visually; however, other techniques may also be used.
### Business requirements
Business requirements and rules provide the foundation and reference for further detailed requirements development. They provide a rationale for why the project is undertaken and the ultimate value it will provide, both to the business and to customers. Business Requirements are not expected to describe in detail the solution to the business needs but to describe what the business wants and needs are.
Specific user requirements and functional requirements should be traced back to business requirements.
#### Business Rules examples:
* conditionally routing documents - _for ex., companies may require multiple rounds of approval for documents like purchase orders;_
* auto-populating fields in a form;
* applying customer discounts;
* creating dynamic picklist options - _for example, for time off requests - populating the number of vacation days available;_
* routing customer service tickets - _for example. routing support tickets to the right department based on a selection;_
* assigning company assets;
* performing calculations automatically;
* validating data fields;
* requiring signatures;
* permission-based access to the system.
### Assumptions, dependencies, and limitations
Any assumptions should be defined and specified in this document when initiating the project. This activity should occur before the project starts to make sure it has a basis for funding.
**Example of assumptions:**
* The project sponsor will provide enough support and attention;
* Resources will be available to staff the project adequately.
* A specific operating system will be available for the designated hardware for the software product.
Any significant dependencies and limitations should be considered to support project success and align stakeholders' expectations. Examples of dependencies may be reliance on specific technologies, third-party vendors, development partners, or other business relationships. In some cases, one project solution may depend on another project's deliverables, so this linkage needs to be identified and its progress - monitored.
The limitations define specific product capabilities, which won't be included and which some people might assume will be there. The scope and limitations help establish realistic stakeholder expectations because customers sometimes request too expensive features outside the intended project scope.
As stated above, assumptions, dependencies, and limitations should be specified. Please note that it is important to label them in such a way that they can be references if needed - uniquely identified will be helpful here.
### Assumptions
| **AS #** | **ASSUMPTION** |
| ---| --- |
| _AS-01_ | _Assumption statement_ |
### Dependencies
| **DE #** | **DEPENDENCY** |
| ---| --- |
| _DE-01_ | _Dependency statement_ |
### Limitations
| **LI #** | **LIMITATIONS** |
| ---| --- |
| _LI-01_ | _Limitation statement_ |
### Non-functional requirements
It is vital to list known non-functional requirements; they must be derived and directly related to business objectives to maintain traceability. Therefore, when thinking about technical trade-offs and making design decisions, the team understands what business objectives they are supporting and which ones might not be fully supported.
The complete list of non-functional requirements can be found in BABOK v.3., section 10.30.3.
Some examples can be found below:
| **REQUIREMENT** | **DESCRIPTION** |
| ---| --- |
| Maintainability | the ability of the system to undergo changes with a degree of ease |
| Understandability | the ability of users to learn quickly to work with the system |
| Reusability | defines the capability of components and subsystems to be suitable for use in other applications |
| Compatibility | the ability of a system to be fully functional across a defined range of technologies (Application Programming Interface (API) compatibility, Browser compatibility, Operating System (OS) compatibility, Virtual Machine (VM) compatibility, Programming language compatibility, Hardware/device compatibility, Character set compatibility |
| Interoperability | the ability of the system or different systems to operate successfully by communicating and exchanging information with other external systems written and run by external parties |
| Manageability | defines how easy it is for system administrators to manage the application |
| Reliability | is the measure of how a product behaves in varying circumstances, the ability of the system to remain operational over time |
| Scalability | the ability of a system to either handle increases in load without impact on the performance of the system or the ability to be readily enlarged |
| Capacity | is the maximum possible capability of the system in a particular dimension. This would typically include: the number of concurrent users, number of concurrent requests, number of concurrent messages processed, total data stored, network packet size, the processing capacity of a CPU, the restoration capacity of a Service Desk, and the power to absorb many changes |
| Security | the capability of a system to prevent malicious or accidental actions outside of the designed usage |
| Availability | the proportion of time that the system is functional and working. Measured as a percentage of the total system downtime over a predefined period |
| Testability | the measure of how easy it is to create test criteria for the system and its components |
| Usability | defines how well the application meets the requirements of the user and consumer by being intuitive |
| Customization | defines the level of customization for an application |
| Integrability | ability to make the separately developed components of the system work correctly together |
| Modifiability | the ease with which a software system can accommodate changes to its software, it fails to work correctly |
| Scalability | how well a solution to some problem will work when the size of the problem increases |
### Scope of the initial release
Describe the intended significant features that will be included in the product's initial release. Consider the benefits the product is intended to bring to the various customer communities, and generally describe the product features and quality characteristics that will enable it to provide those benefits. Focus on those features and product characteristics that will give the most value, at the most acceptable development cost, to the broadest community, in the earliest time frame. You might include a [**feature tree**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-8708) (or other types of) diagram here.
### Scope of next releases
If a staged evolution of the product is envisioned over time, indicate a numbered list of the significant features that will be deferred to later releases emphasizing those features that distinguish it from previous or competing products. Specific stakeholder requirements and functional requirements may be traced back to these features. Consider developing a more detailed scope for each iteration and placing it into that iteration's documentation.
### Out of Scope
Similar to the solution Scope (which describes functionality that is supposed to be implemented in the solution), the Out of Scope section defines a limited set of features and functions excluded from a product or solution - the features and functions that fall outside its boundaries. It may be helpful to identify and write down on the paper any solution features or characteristics that a stakeholder or customer might anticipate but which are not planned to be included in the new solution.
## Template
[https://docs.google.com/document/d/1yMqfEtxApXiTHRlQbnlMcZo0ILFU-SXzUpxlZ4w7NWM/edit?usp=sharing](https://docs.google.com/document/d/1yMqfEtxApXiTHRlQbnlMcZo0ILFU-SXzUpxlZ4w7NWM/edit?usp=sharing)
# Stakeholder Profiles
The stakeholder profiles describe different categories of customers and other key stakeholders for the project. It focuses on different types of customers, target market segments, and the various user classes within those segments.
# Stakeholder Profiles
| **STAKEHOLDER** | **MAJOR VALUE** | **ATTITUDES** | **MAJOR INTERESTS** | **CONSTRAINTS** |
| ---| ---| ---| ---| --- |
| **_Corporate management_** | **_Improved employee productivity; cost savings_** | **_Strong commitment to releases 1 and 2. Support for release 3 in case of success of previous releases._** | **_Cost and employee time savings must exceed development and usage costs_** | **_None Identified_** |
| **_Sales Managers_** | **_Increased sales_** | **_Receptive but cautious_** | **_Minimal training and new technology adoption_** | **_Might not have the capacity to handle order levels._** |
# Context Diagram
# Context Diagram
The scope description establishes the boundary and connections between the system, which should be developed, and everything else. The context diagram visually illustrates this boundary. It identifies external entities (also called terminators) outside the system that interact with it in some way, and data, control, and material flows between the terminators and the system. The context diagram is the top level in a data flow diagram developed according to the principles of structured analysis (Robertson and Robertson 1994), but it’s a valuable model for all projects.
More details on Context Diagrams can be found in BABOK v.3., section 10.13.2 and Wiegers 2013 (Chapter 5, Scope representation techniques).
# **Context Diagram Example**
# Feature Tree
A feature tree is a visual representation of the product's features, organized in logical groups. The feature tree provides a concise view of all of the features planned for a project, what's particularly helpful to have a quick presentation of the project scope to executives. A feature tree can show up to three levels of features, commonly called level 1 (L1), level 2 (L2), and level 3 (L3). L2 features are sub-features of L1 features, and L3 features are L2 features.
## Example from Wiegers, 2013 of the Feature tree for Chemical Tracking System
The main branch of the tree in the middle represents the product being implemented. Each feature has its line or “branch” coming off that main central branch. The yellow boxes represent the L1 features, such as Order Chemicals and Inventory Management. The lines coming off an L1 branch are L2 features: Search and Chemical Request are sub-features of Order Chemicals. The branches of an L2 branch are the L3 features: Local Lab Search is a sub-feature of Search.
When planning a release or an iteration, you can define its scope by selecting a specific set of features and sub-features to be implemented (Nejmeh and Thomas 2002; Wiegers 2006).
You could implement a feature in its entirety in a specific release or implement only a portion of it by choosing particular L2 and L3 sub-features. Future releases could enrich these rudimentary implementations by adding more L2 and L3 subfeatures until each feature is fully implemented in the final product. The scope of a particular release consists of a defined set of L1, L2, and/or L3 features chosen from the feature tree.
# Requirements Management Plan
The requirements management plan provides all project stakeholders with essential guidelines about requirements management processes. The purpose of this plan is to establish and document a systematic approach to organizing and writing the requirements for a particular project, including managing requirements changes.
# Requirements Management Plan Sections
## General information
This section contains general project-specific information, which might be necessary for requirements management activities, in particular requirements workflow.
Example: _Project requirements are maintained through different issue management and wiki systems (Jira and Confluence), incorporating information from emails, conference calls, chats, and meetings._
_Due to the Agile Scrum process selected, BA and PO are more focused on the frequency of communication than on formal documentation processes. Project communications are conducted according to the_ [**_Communication plan._**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7082) _Additionally, ad-hoc or on-demand communications are held if needed._
## Stakeholders register (optional)
You can skip this section if Stakeholders are listed according to [**Stakeholder Management Guidelines**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3721) by AM/PM
[List](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7482) the project members and Client stakeholders that primarily influence requirements management activities.
## RACI Matrix (optional)
Depending on the project size and its needs, you may include [**RACI matrix**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7522). This matrix describes the participation of various roles in completing tasks or deliverables for a project. It helps to bring structure and clarity to defining the roles that stakeholders play within a project and clarify responsibilities to ensure that all essential project tasks/deliverables are assigned to someone.
## Agile
If Scrum methodology was selected for project implementation, add its short description. Describe the following elements:
* Product [**Backlog**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7542?block=block-eae8a3f3-2ac9-49c5-9715-7a4ac57fe1b4)
* Characteristics of [**Agile Requirements**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7562?block=block-69dee0a4-3f42-445e-8c85-6840c87dba3b) (optional)
* [**Backlog refinement**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7542?block=block-89b70fdc-b224-4049-ab14-893a0b7143e2)
* [**Estimation**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4121)
* [**Prioritization**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7542?block=block-99f9f9d7-e6f8-485a-8cd3-2b97fb2df1f4)
* [**Definition of Ready**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7602)
* [**Sprint Planning**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4001)
* [**Sprint Review**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4381)
* [**Change management**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7702)
* [**Acceptance**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7942)
* [**Definition of Done**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5341)
**_In case of any other methodology is chosen, add a relevant description._**
## Requirements Format
Describe all types of requirements used on the project and their representation. List the [**requirements attributes**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7642) and briefly explain what they are used for.
If you use [**User Stories**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7662), add a template.
Use the [**User Story Quality Checklist**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-10181) to ensure your requirements are well-defined and cover the needed details.
You may also use [**Use Cases**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7682) for more complex functionality and a more formal approach for requirements specification.
## Template
[https://docs.google.com/document/d/176TBxNcRVFfLlbrlnp\_AN0HFlx4ET9yGteXY64XXk\_Q/edit?usp=sharing](https://docs.google.com/document/d/176TBxNcRVFfLlbrlnp_AN0HFlx4ET9yGteXY64XXk_Q/edit?usp=sharing)
# RACI Matrix
RACI matrix is a simple and effective tool for defining and documenting project roles and responsibilities. Knowing exactly who is responsible, who is accountable, who needs to be consulted, and who must be kept informed at every step will significantly contribute to the project's success.
RACI stands for **Responsible**, **Accountable**, **Consulted**, and **Informed**. Each of these words describes the person’s role, and the last two are differentiated by what type of communication they should engage in during the project.
**Responsible** - Assigned to complete the task or deliverable
**Accountable** - Has final decision-making authority and accountability for completion. Only 1 per task/deliverable.
**Consulted** \- an adviser, stakeholder, or subject matter expert (SME) who is consulted before a decision or action
**Informed** \- Must be informed after decision or action.
# Template
[https://docs.google.com/spreadsheets/d/1gLAXkBfJ\_NeW1ZBMCTwrum0atipPg8Dlwei0zxW78dk/edit?usp=sharing](https://docs.google.com/spreadsheets/d/1gLAXkBfJ_NeW1ZBMCTwrum0atipPg8Dlwei0zxW78dk/edit?usp=sharing)
# Agile
# Agile Requirements
It is essential to accept that requirements do not have to be documented very formally to follow Agile philosophy. In change-driven approaches to software development, requirements are elicited, analyzed, communicated, prioritized, and used to develop working software with very little formal documentation. Such a requirement handling approach does not make them less critical but instead makes it even more essential for Business analysts to understand the differences between their types and know which requirements are needed at each level of agile planning and development.
Standard requirements activities (elicit, specify, analyze, validate) occur within each agile iteration. BA facilitates the team's discussion of requirements to the level of detail developers need to build the product accurately.
# Scrum
Scrum is a widely used methodology in Agile. It is based on performing a series of iterations, called sprints, usually lasting from 2 to 4 weeks. At the end of each sprint, potentially shippable product increment of decent quality should be produced.
Agile Software Development Projects have the following characteristics:
* It is expected that requirements would change;
* Working software is delivered in iterative short cycles;
* Business analysis activities focus on performing the analysis activities in **'just enough, just in time'** manner; there is no need to create lengthy software specifications unless there is an area of complexity that requires it.
# Ceremonies
[**Backlog refinement**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7542?block=block-89b70fdc-b224-4049-ab14-893a0b7143e2)
[**Sprint planning**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4001)
**Daily Stand-up**
[**Sprint Review**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4381)
[**Sprint Retrospective**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5421)
# Business Analysis and Scrum
Business analysis activities are not addressed in Scrum in detail. Product backlog creation, update, and maintenance is a significant BA activity outside of the scrum framework scope. Backlog is developed in collaboration with the client, usually Product Owner. BA focuses on specifying the requirements and acceptance criteria (AC) for the backlog user stories during a sprint.
Specific user stories might have little detail provided, with only the riskiest or highest-impact functionality being well specified, typically in the form of acceptance criteria. AC helps define only the minimum required set of requirements for the current sprint to enable the team to build the next product iteration with testable acceptance criteria.
However, to ensure requirements quality, they should satisfy [**the Definition of Ready**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7602), so once [**Backlog refinement**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7542?block=block-89b70fdc-b224-4049-ab14-893a0b7143e2) is done, a team can concentrate on the development rather than requirements clarification. Often the backlog documentation created within each sprint is sufficient for the project. Documentation may also be completed after the product is built to capture the team's knowledge.
# Backlog
# Backlog Items
In Scrum, a product backlog is a list of requests for work, including technical and stakeholder requirements. The backlog acts as a wish list for the product. Product backlogs typically are composed of user stories, but some teams also populate the backlog with other requirements, business processes, technical tasks, and defects to be fixed.
The common Product Backlog Items (PBI)
As the team collaborates with customers, the Backlog grows and changes to encompass all requests. Backlog is periodically prioritized so that at any given time, stakeholders have a common understanding of what requests should be selected for the development first. When each sprint starts, the team reviews the prioritized Product Backlog during the sprint planning and identifies which highest priority items could be implemented during the sprint. These items are part of the Sprint Backlog, which outlines the goal of the sprint, and tasks should be completed within this iteration.
# .png)
# Backlog Decomposition
Usually, user stories are the format for user requirements at Agile projects. A user story is a concise statement to articulate a user's needs and serves as a starting point for conversations to flash out the details.
When exploring user requirements, you might prefer to employ use cases, features, or process flows. The form you choose to describe these requirements is not important, however, a user story is commonly used on Agile projects.
**User stories** are sized to be fully implementable in a single iteration.
An **Epic** is a user story that is too large to implement in a single iteration fully. Thus, such epics are split into features and smaller user stories to fit into separate iterations.
Sometimes epics are large enough so that they must be subdivided into multiple features, each of which is then split into numerous stories until each resulting story can be reliably estimated and then implemented and tested within a single iteration.
User stories can contain multiple tasks. Tasks are created by the Development Team and they include all actions required to complete the user story, to make it “Done”. Definition of “Done” is defined by the Development Team and used to recognize the status of the user story.
## 
## Approvals
An approval formalizes the agreement between all stakeholders that the content and presentation of the requirements and designs are accurate, adequate, and contain sufficient detail to allow for continued progress.
The Business analyst must determine the type of requirements and designs to be approved, the timing for the approvals, the process to follow to gain approval, and who will approve the requirements and designs
# Backlog Refinement
# Guidelines
[Ukrainian version of this guideline](https://docs.google.com/document/d/1lRjfndVIwULQ4J8csHYyxw44uA2a5KgEWh-vurXoejw/edit?usp=sharing)
Backlog refinement is an ongoing activity, which helps to get a shared understanding of what the Product will and won’t do, the effort needed to implement it, and the order in which the team should do that. In addition, the team ensures that items on top of the Backlog are ready for implementation; in practice, this standard is often called a **“**[**Definition of Ready”**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7602), which is easy to use as a checklist to guide this activity.
In effect, Product Backlog refinement helps to de-risk Sprint planning. The team usually needs to reserve about 10% of the time during the Sprint to perform quality Backlog refinement. This process requires discipline; it considerably simplifies Sprint planning and saves time during implementation.
The main aim of this activity is to ensure the body of work selected is well understood, and that the team can make a fair commitment to its implementation.
## Backlog refinement tasks
Some of the activities that occur during this refinement of the backlog include:
* removing user stories/tasks that are no longer relevant
* creating new user stories/tasks in response to newly discovered needs
* re-assessing the relative priority of stories/tasks
* assigning estimates to stories/tasks that were not estimated yet
* correcting estimates in light of newly discovered information
* splitting high-priority user stories/tasks that do not fit into the upcoming iteration
The Backlog is understood as a dynamic body of information. For instance, not all user stories need to be broken down to a fine-grained level at the beginning of the project or given detailed estimates; **but it is important that at any moment, a “sufficient” number of stories should be ready for scheduling in the next few iterations (at least for the next 2 iterations).**
### Backlog refinement meetings organization
**When:** The Backlog refinement meeting may be scheduled at any time during development iteration depending on the need: discovering details of high-level requirements, adding acceptance criteria, and finalizing requirements to be ready for implementation or as a sanitary procedure to make sure the Backlog is up to date.
**Who:** there is no need to invite the whole team to each refinement. The PO and BA are required as they are the main facilitators and collaborate in terms of ticket prioritization and articulating and capturing the business benefit, business requirements, and rules related to those tickets. Other business stakeholders and dev team representatives are invited depending on the tickets, which are planned to be reviewed to make sure only those people are present who can contribute.
It is recommended to prepare an agenda before each refinement to plan the tickets, which should be discussed, and have time boxes for each (about 5-10 minutes each) to minimize irrelevant discussions.
### Prioritization
Key things to take into account while prioritizing are cost, risk, and value.
Backlog prioritization is performed on an ongoing basis. It means selecting which work items go into upcoming iterations and which items are discarded. The priorities assigned to backlog items may change with time; they may vary just for the next iteration. It is vital to trace requirements back to the business requirements to facilitate prioritization.
According to Alan Davis (2005), successful prioritization depends on six issues:
* The needs of the customers
* The relative importance of requirements to the customers
* The timing at which capabilities need to be delivered
* Requirements that serve as predecessors for other requirements and other relationships among requirements
* Which requirements must be implemented as a group
* The cost to satisfy each requirement
#### Prioritization techniques
#### Three-level scale
According to this methodology to high, medium, and low priority. However, to make such a prioritization scale more precise, it would be relevant to add two dimensions - importance and urgency.
.png)
* **High-priority** requirements are important (customers need the capability) and urgent (customers need it in the next release). Alternatively, contractual or compliance obligations might dictate that a specific requirement must be included, or there might be compelling business reasons to implement it promptly. If you can wait to implement a requirement in a later release without adverse consequences, then it is not a high priority per this definition.
* **Medium-priority** requirements are important (customers need the capability) but not urgent (they can wait for a later release).
* **Low-priority** requirements are neither important (customers can live without the capability if necessary) nor urgent (customers can wait, perhaps forever).
* **Requirements in the fourth quadrant** appear urgent to some stakeholders, perhaps for political reasons, but they aren’t crucial to achieving the business objectives. Don’t waste time working on these because they don’t add sufficient value to the product. If they aren’t important, either set low priority or scrub them entirely.
#### **MoScoW Technique**
This method uses four priority groups: MUST have, SHOULD have, COULD have, and WON'T have. With this technique, stakeholders can collaboratively prioritize requirements. The acronym represents the following:
* MUST (Mandatory)
* SHOULD (Of high priority)
* COULD (Preferred but not necessary)
* WOULD (Can be postponed and suggested for future execution)
### Estimation
During backlog refinement activity, the backlog items are estimated so that the team can make a fair commitment to the number of items selected for the next iteration's development. Each team sets its estimation approach. Please check [**Estimation techniques**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4121) for more details.
**Recommended readings:**
[
8 Different Ways to Organize Your Backlog to Make it More Impactful
Linear backlogs are so yesteryear
https://productcoalition.com/8-different-ways-to-organize-your-backlog-to-make-it-more-impactful-a472684d093b
](https://productcoalition.com/8-different-ways-to-organize-your-backlog-to-make-it-more-impactful-a472684d093b)
# Definition of Ready
TEXT in **_bold_** **_italic orange (_****_including links in_** **_light blue_****_)_** is meant to be adopted by each project.
# Definition of Ready for Starting User Story Implementation
* All acceptance criteria are finalized
* All acceptance criteria are testable
* All assumptions and dependencies are listed (if applicable)
* All applicable mock-ups or/and other documentation are attached to the **_story_**
* A **_user story_** is discussed with a team, and the team has a clear understanding of what should be done.
## Definition of Ready for starting a Sprint
* All sprint **_user stories_** are Ready
* All sprint **_user stories_** are estimated in **_story points_** with proper granularity
* All **_user stories_** are verified and approved by the **_Product Owner._**
# Requirements Format
# Requirement Format
Each requirement should have attributes associated with it. These attributes establish a context and background for each requirement. Attribute values can be stored in a spreadsheet or, most effectively, a requirements management tool; usually, Jira or Confluence are used for these needs.
The following requirement attributes should be considered:
* Requirement ID (ex. US-1)
* Date the requirement was created
* An author who wrote the requirement
* Priority
* Status
* Origin or source of the requirement
* The rationale behind the requirement (user benefit)Дек
* Release the number of iterations to which the requirement is assigned (_fix version in Jira_)
* Contacts of stakeholders to make decisions about proposed changes (in comments or _Confluence_)
* Acceptance criteria
# Product Requirements Template
Please check the [**General Guidelines**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3981) for more information
TEXT in **_bold_** **_italic orange (_****_including links in_** **_light blue_****_)_** is meant to be adopted by each project.
# Specification Template
The specification template must be stored within the documentation tool
### **_Specification Name_**
| **PLANNED SPRINT** | |
| ---| --- |
| **EPIC** | |
| **DOCUMENT STATUS** | **_DRAFT_** |
| **DOCUMENT OWNER** | |
### Success metrics
| **GOAL** | **METRIC** |
| ---| --- |
| _e.g., Simplify the user experience_ | _e.g., Customer satisfaction score increases_ |
| | |
### Requirements
| **USER STORY/TASK** | **DESCRIPTION** | **ACCEPTANCE CRITERIA & CONSTRAINTS** | **PRIORITY** | **TASK LINK** |
| ---| ---| ---| ---| --- |
| _e.g., Must be mobile responsive_ | _e.g., John is a PM who wants to check on his team's progress from the train station_ | | | |
| | | | | |
### Assumptions
_List any assumptions you have about your users, technical constraints, or business goals (e.g., Most users will access this feature from a tablet)_
### User interaction and design
_Add mockups, diagrams, or visual designs related to these requirements. Type /image to upload a file._
### Milestones
_Use milestones as major achievements within the scope of the specification_
### Open Questions
| **QUESTION** | **ANSWER** | **DATE ANSWERED** |
| ---| ---| --- |
| _Are Support reps aware of this feature?_ | _e.g., We'll announce the feature with a blog post and a Summit presentation_ | |
### Out of Scope
_List the features discussed which are out of scope or might be revisited in a later release._
# User Requirements Specification
User requirements describe what a user expects the software to be able to do. Those can be captured as a User Story or a Use case. User requirements provide information that serves as the basis for further specification, design, and verification of a software system system
# Use Case
The use case is a type of requirements specification that captures exactly how a user will interact with a software system to achieve a specific goal. Accumulating all the ways of using a system (use cases) enables us to define all the goals or requirements of the system.
# **Example:**
| **US -1** | User registration |
| ---| --- |
| **Description** | Create a User account |
| **Actor** | Admin |
| **Pre-conditions** | Admin is logged in |
| **Main scenario** |
|
| **Alternative scenario** | 3.a. The Admin cancels the operation
3.a.1. The system displays a warning message
3.a.2. IF Admin confirms cancellation - the system stops the
operation,
ELSE - the system goes to step 3 of the Main scenario.
4a. Data that was filled in is incorrect
4.a.1. The system notifies the Admin about particular validation
errors and goes to step 3 of the Main scenario |
| **Post-conditions** | The new system account is created. The User is notified about that |
# **Template:**
[https://docs.google.com/spreadsheets/d/1FN7zzGiQyNaMNRvuP-zJ8w7E\_jvIgC6VMZHznJd6YD4/edit?usp=sharing](https://docs.google.com/spreadsheets/d/1FN7zzGiQyNaMNRvuP-zJ8w7E_jvIgC6VMZHznJd6YD4/edit?usp=sharing)
# User Story
# **User Story**
As used on agile development projects, a **User Story** is a “short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system” (Cohn 2010).
A user story should have the following sections:
### Description (mandatory)
A short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:
**As a** \[description of the user (User Role)\]
**I want** \[functionality (activity)\]
**So that** \[benefit\]
**Example:**
**_As a_** _user,_
**_I want_** _to be able to recover the password to my account,_
**_so that_** _I will be able to access my account in case I forgot the password._
While Cohn has designated the **\[benefit\]** part of the template is optional, it is standard practice nowadays to specify a benefit for every user story.
### **Acceptance criteria (mandatory)**
**Acceptance criteria** cover functional and non-functional requirements to the story and pass/fail user scenarios; they define when Story is "Done", so when all acceptance criteria are met, the Story is accepted and considered to be "Done". You may use several Templates to specify Acceptance criteria.
Depending on the initial task and the complexity of requirements, acceptance criteria may be written in different formats:
**Scenario-oriented (Given/When/Then)**
GIVEN \[how things begin\]
WHEN \[action is taken\]
THEN \[outcome of taking action\]
AND \[used to continue any of previous statements\]
**Example:**
GIVEN the user navigates to the login page,
WHEN the user selects option,
AND enters a valid email to receive a link for password recovery,
THEN the system sends the link to the entered email.
**Rule-oriented acceptance criteria format**
This might be represented as a bullet list with a set of rules that describe the behavior of a system. Based on these rules, you can draw specific scenarios.
**Example:**
**User story:** _As a user, I want to use a search field to type a city, name, or street, so that I could find matching hotel options._
**Acceptance criteria:**
* The search field is placed on the top bar
* The field contains a placeholder with a grey-colored text: “Where are you going?”
* The placeholder disappears once the user starts typing
* Search is performed if a user types in a city, hotel name, street, or all combined
* The user can’t type more than 200 symbols
* The search doesn’t support special symbols (characters). If the user has typed a special symbol, show the warning message: “Search input cannot contain special symbols.”
Check the [User Story quality checklist](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-10181) to define what options you might want to consider while specifying acceptance criteria.
### **Assumptions and Constraints (optional)**
Any assumption or consideration the development team needs to keep in mind before developing the user story.
You may add assumptions and constraints as a list:
* item 1
* item 2…
### Questions and Notes (optional)
If you have any questions to be clarified before the User Story may be deemed [Ready](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7602) for implementation, add them in this section. In the same way, you may add notes, which are important for the team to understand the context or any other details.
A good user story should be concise and independent. These characteristics are well described with INVEST principle:
**“I” Independent:** The user story should be independent enough to avoid dependencies on other user stories, which allows for flexibility during iteration planning. If user stories depend on one another, we combine smaller user stories to be completed within the same iteration.
**”N”** **Negotiable:** until implementation starts, User stories can always be changed or rewritten to allow flexibility according to Agile principles (they can evolve, rise, or fall in priority).
**”V” Valuable.** A User Story represents a goal of an end-user and should deliver functionality that is deemed valuable. The specifics of the technical design are not something that you would document as user stories. However, some technical requirements have a valuable component to a user.
**”E” Estimable.** We should be able to estimate the size of a user story.
**”S”** **Sized Appropriately**. User stories should not be too big or too small. Any user story that can’t be completed within a single iteration is considered too big and should be split into smaller pieces.
**”T”** **Testable.** User stories must be testable to ensure that development is complete and has been done correctly.
# Template
**As a** \[description of the user (User Role)\]
**I want** \[functionality (activity)\]
**So that** \[benefit\]
**Acceptance criteria:**
* item 1
* item 2
**Mock-ups:**
**Assumptions and Constraints:**
* item 1
* item 2
**Questions and Notes:**
* item 1
* item 2
# User Story Quality Checklist
### **All necessary User Story sections are ready:**
- [ ] - [ ] **Description**
- [ ] User role defined (As a User)
- [ ] User task defined (I want to)
- [ ] User value defined (So that)
- [ ] - [ ] **Acceptance Criteria**
- [ ] where the process starts
- [ ] what are the User/system steps?
- [ ] where the process ends
- [ ] are all alternative scenarios taken into account?
- [ ] what happens if the User or the system fails to accomplish any of the steps?
- [ ] does this change affect any other places? (_ex. display new feature on the Product Details page and Product listing page_)
- [ ] are any important system qualities (performance, security, response times, etc.) noted (if applicable)?
- [ ] are relevant UI, data, etc. requirements (see the [list](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-11560)) taken into account? (if applicable)
- [ ] - [ ] **Assumptions and Constraints** (where applicable)
- [ ] **Notes/Questions** (where applicable)
- [ ] **UI mock-ups** attached (where applicable)
- [ ] **Supporting files** are attached (where applicable)
# Requirements Quality Checklist
### **Requirements quality checklist**
#### UI and Data elements
Buttons or controls
- [ ] behavior when enabled/disabled
- [ ] any actions on hover?
- [ ] any changes on click?
Fields
- [ ] length (min/max)
- [ ] behavior for exceeding max length (cut or validate)
- [ ] behavior for entering less than min values
- [ ] type (text/html/integer/date/email...)
- [ ] format ("MM-DD-YYYY", : \[login\]@\[domain\].\[ext\])
- [ ] validation of format
- [ ] behavior when not valid
- [ ] allowed characters: \[A-Z a-z 0-9 . , \_ - ! @ # $ % ^ & \* ( ) + = { } \\ | / < > ~ \` ' : ; "\], space.
- [ ] behavior if not allowed characters entered
- [ ] If a field is empty - what should be displayed?
- [ ] placeholders, tooltips
- [ ] Any pre-filled fields?
- [ ] Any limit on the frequency of input (_for example for password fields_)
- [ ] Required: yes/no
- [ ] in what cases is required?
- [ ] validation on required fields?
- [ ] behavior when not valid
- [ ] Unique: yes/no
- [ ] validation on uniqueness
- [ ] behavior when not unique
- [ ] Modifiable: yes/no
- [ ] cases when modifiable (if applicable)
Check box
- [ ] Required: yes/no
- [ ] Default value (checked/unchecked)
- [ ] Behavior if checked
- [ ] new functionality added (new fields, new alternate variables) - _e.g. 'I pay Taxes - YES - requires to upload TaxID)_
Popup
Think of behavior for different types of popups:
- [ ] informative with no action items (_ex. close button_)
- [ ] with given options (_e.g. save a Credit Card for the next purchase_)
- [ ] consider all alternative variants
- [ ] warning popup
Images
- [ ] size
- [ ] maximum number
- [ ] what is displayed when the image is not available?
- [ ] any other limitations?
Files
- [ ] maximum size
- [ ] what is displayed when the file is not available?
- [ ] type of file
#### Compatibility
Browser compatibility
- [ ] what browsers are supported
- [ ] what versions of browsers are supported
Device compatibility
- [ ] what devices are supported?
- [ ] what resolutions?
#### Permissions
- [ ] Are user permissions limitations taken into account?
# System requirements specification
### EARS Requirements Specification Patterns
EARS stands for the Easy Approach to Requirements Syntax, developed by Alistair Mavin a requirements specialist at _Rolls_\-_Royce PLC_, and his colleagues. It represents the set of rules on how to structure textual requirements to avoid ambiguities and unexpected interpretations. Those rules use a small number of keywords and clauses, which are always in the same order and are close to the common usage of English, so are intuitive and easy to capture and interpret.
You may use the following EARS patterns:
**General:**
The shall
**Example**: _The system shall accommodate 1000 Users._
**Event-driven requirements (triggered by an external event):**
**WHEN** the shall
**Example:**
* WHEN the Order quote has been approved and Job is completed, the system shall create an Invoice.
* WHEN a user answers "Yes" to "Do you pay taxes?" question, the system shall require him/her to enter a Tax ID.
**Optional behavior (describing the situations to be avoided. Response to failures and undesired behavior):**
**IF** , **THEN** the shall
**Example:** IF an invalid credit card number is entered, THEN the website shall display “please re-enter credit card details”.
**State-driven requirements (apply only in certain states):**
**WHILE** the shall
**Example:** WHILE the file is uploading, the system should display a progress bar.
**Optional features (applicable only if some feature is included in the system):**
**WHERE** the shall
**Example:** WHERE the Recommendations feature is opted for, the System shall list recommended products in the gallery at the bottom of the webpage.
**Complex**
This is a combination of the above patterns
**Example:** WHILE the Vehicle is "In transit' status, IF the Driver selects "Check-In", THEN the system shall display a Notification "Change the Vehicle status to "Delivered".
# Change Management
# Change Management
[Ukrainian version of this guideline](https://docs.google.com/document/d/15kozwvWwr9LyikZot6NXkOTjVfcpDUGPcrPKIfA2Ejw/edit#)
First of all, determine and specify which requirements and designs the change control process covers and determine whether it applies to all changes or only to changes of a specific size, cost, or level of effort.
Agile welcomes requirement changes and a change control should be in place to mitigate the risk of scope creep. At the beginning of the project, it is crucial to establish a mutually acceptable change control process using a standard template for handling change requests (ex. [**Change Register**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7742)). Change always has a price, so using change management practices to control scope creep is vital in a contract-development situation (Wiegers 2003). It is essential to identify who is eligible to propose the change and which stakeholders should be informed.
**Example of the change procedure:**
* _Any kind of changes to the user stories for the upcoming sprint may be introduced before the internal sprint planning meeting._
* _User stories could be introduced between the internal planning and the actual sprint start if they do not significantly influence the total story estimate. In this case, the project team should be notified via communication tools (messenger, email)._
* _The scope should not change after the sprint has started, and changes can only be made on request._
* _Approval of a requested change must be obtained from the team members, confirming that this change is feasible to implement in the current sprint._
## _The change request activity includes the following steps_
1. **_Identify change requests_** _(additional functionality requests, enhancements, defects, etc.)._
2. **_Analyze and Validate change requests_** _before all the interested parties are notified. The PO, BA, and PM are responsible for approving, rejecting, or deferring change requests._
3. **_Scope change requests_** _can result from changes or additions to the requirements. They can also result from changes to the deliverables, activities, or quality standards. Scope change requests include additions, deletions, and changes to the elements._
4. **_A defect_** _is an error, mistake, or failure in a product that prevents it from behaving according to the specification. Defects found in the implemented functionality during functional, regression, or acceptance testing are fixed in the release scope and are not considered a change request._
5. _Once a change request is identified and all the interested parties are notified, the PM and other appropriate team members_ **_perform an impact and risk analysis_** _of the change request and inform the PO and BA about the outcome. The outcomes of this analysis are captured in the_ [**_Change Register._**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7742)
6. _Only PO, PM, and BA can_ **_approve_**_, reject or defer change requests. Changes to the scope, schedule, or resource allocations must be approved in a formal meeting or email._
# Requirements Change Register
The change register is used to track requirements changes and their impact on project scope.
# Template
[https://docs.google.com/spreadsheets/d/1AIa0dwtPicggHrHXVxNDfFCvyeVRoxj8rWcrYSzOqEo/edit?usp=sharing](https://docs.google.com/spreadsheets/d/1AIa0dwtPicggHrHXVxNDfFCvyeVRoxj8rWcrYSzOqEo/edit?usp=sharing)
# Acceptance
# Example of Acceptance Procedure
* Acceptance is performed by the BA, PO, and other stakeholders.
* Each story needs to pass internal QC acceptance first. Acceptance testing verifies that stories were developed in such a way that each works exactly how the customer team expected it to work (check [**Definition of Done**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5341)).
* BA evaluates the implementation of the business and stakeholder requirements to conform to the user story description and understanding.
* A demo is held for all the stakeholders at the end of the sprint. PO should accept the result and/or give feedback on what should be modified. New backlog items (tasks and stories) are created as an output.
* Minor tasks can be fixed during the next sprint unless stakeholders agree during a demo. Meeting notes with appropriate action items are added and stored in the project documentation space. Demo sessions are held according to the [**BA Communication Plan**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7082) Schedule.
# Communication Plan
The purpose of the Communication Plan is to establish clear communication processes between project stakeholders. It defines the key audiences, channels, and frequency of communication, as well as the escalation path.
# Communication plan sections
## General rules
Describe general information valuable for Business Analysis communication processes.
**_For example:_** _according to the Agile Scrum_ _methodology adopted for the project, stakeholders are focused on the frequency of communication rather than formal documentation processes. Project communication takes place by means of email, conference calls, chats, and meetings._ [_Meeting flow_](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3921) _example._
## Stakeholders register
If this register was not created by AM or PM earlier, list the project members and сlient stakeholders which influence requirements management activities. [See the](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7482) [example.](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7482)
## Organizational Structure
You can add an organization chart if available.
## Meeting Schedule
Add the schedule of meetings with the client and other project stakeholders related to the requirement management. For example, spring planning, sprint review, backlog refinement, regular syncs with the client (ex. PO), demo, etc.
Schedule might be complemented with working hours, what's especially helpful while working with teams distributed across different time zones.
## Escalation
Describe the process of escalation related to requirements conflicts and/or blockers. This process may be enhanced to escalation on different levels: strategic, cooperation, project, and product. All responsible persons for the process must be listed in the Stakeholder register.
## Tools
Provide a list of communication tools used in the project.
**Example**
| **TOOL** | **ACCESS** |
| ---| --- |
| **_Jira_** | |
| **_Confluence_** | |
| **_Slack_** | |
| **_Skype_** | |
## Meeting Notes
Add a Template for Meeting notes, which would be helpful to align the relevant stakeholders on the meeting outcomes.
# Template
[https://docs.google.com/document/d/1hevTXXKRuQ4KhWHmvn-Z52VyZkVpUiHwPuAvIOMPplU/edit?usp=sharing](https://docs.google.com/document/d/1hevTXXKRuQ4KhWHmvn-Z52VyZkVpUiHwPuAvIOMPplU/edit?usp=sharing)
# Stakeholders Register
A stakeholder register is essential for performing stakeholder collaboration activities. Managing stakeholder collaboration is an ongoing activity that begins once stakeholders have been identified and analyzed. New stakeholders may be identified during an initiative; their role, responsibility, influence, attitude, and authority may change over time, so the Stakeholder register should be a "living" document updated regularly.
Please check the [**General Guidelines**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3721) for more information.
You may use [**Power Interest Grid**](https://www.youtube.com/watch?v=2QhvKlQhleQ) to analyze Communication frequency.
TEXT in **_bold_** **_italic orange (_****_including links in_** **_light blue_****_)_** is meant to be adopted by each project.
| **NAME** | **POSITION (ROLE)** | **RESPONSIBILITY** | **CONTACT INFO** | **LOCATION / TIMEZONE** | **COMMUNICATION FREQUENCY** |
| ---| ---| ---| ---| ---| --- |
| **_First and Last Name_** | **_e.g. BA, PO, PM, TL, responsibility_** | **_responsibility on the project_** | [**_user@devcom.com_**](mailto:user@softserveinc.com) | **_City, time zone_** | **_manage close_** |
# Meeting Schedule
TEXT in **_bold_** **_italic orange (_****_including links in_** **_light blue_****_)_** is meant to be adopted by each project.
**_Provide the Business Analysis Communication Plan meetings details._**
# Meeting Schedule
| **NAME** | **PURPOSE** | **RECURRENCE** | **PARTICIPANTS** | **TOOLS** | **ORGANIZER** |
| ---| ---| ---| ---| ---| --- |
| **_e.g. Demo_** | **_Meeting purpose_** | **_Meeting duration, occurrence, time & time zone_** | **_e. g. , TL, BA, PM, PO_** | **_Communication tools_** | **_e.g. BA, PM_** |
## Working Hours / Time Zones
| **TIME ZONE** | **DEVCOM** | **CLIENT** |
| ---| ---| --- |
| **_EET (GMT +2:00)_** | **_e. g. 10:00 – 19:00_** | **_e. g. 2:00 AM – 11:00 AM_** |
| **_CST (GMT -6:00)_** | **_e. g. 16:00 – 01:00_** | **_e. g. 8:00 AM – 5:00 PM_** |
# **Meeting Schedule Example**
| **NAME** | **PURPOSE** | **RECURRENCE** | **PARTICIPANTS** | **TOOLS** | **ORGANIZER** |
| ---| ---| ---| ---| ---| --- |
| **Daily sync** | Align stakeholders on project status, and clarify open questions. | Daily,
8:30 - 9:00 AM EST | PO, BA, PM, dev team | Zoom | PM |
| **Sprint Planning** | Select items for the next sprint based on the priority and preliminary work estimates. | Each second Thursday
8:30 AM - 10:30 AM EST | PO, PM, dev team | Zoom | BA |
| **Backlog Refinement** | Develop a clear understanding of the items that were selected for the next sprint and get the team's commitment to their implementation. | Tuesdays
9:00 AM - 10 AM EST | PO, BA, PM, dev team | Zoom | BA |
| **Demo** | To demonstrate the completed work and get feedback. | On-demand | Sponsor, PM, PO, BA, dev team | Google Meet | PO |
| **Retrospective** | Evaluate the team's past working cycle | Once per release, after sprint planning
10:30 AM - 11:30 AM EST | PM, BA, dev team | Google Meet | PM |
# Meeting Agenda
An Agenda is a critical tool for running an effective meeting. When you received an initiation for a meeting, you want to know who is invited, what the purpose of the meeting is, and what the organizer wants to accomplish. You want to provide that in advance so people know why the meeting is important and what they can hope to get done while they’re there.
Follow the next steps to prepare an effective agenda:
1. **Identify the goal of the meeting.** The goal may be to review a requirements document or to get ideas about new features etc.
2. **Identify meeting topics.** Based on the defined goal list topics to discuss. You might add time limits for discussion of each topic to make sure your meeting won't get extended too much and you cover all topics planned. For example, if the meeting goal is to get ideas about new features, the topics might be as follows:
* Short intro, [ice breaker](https://toggl.com/blog/icebreaker-questions) (10 min)
* Brainstorming to get ideas for new features (25 min)
* Review of the generated ideas (25 min)
3. **Prepare support materials.** Make sure you attach all needed documents, diagrams, etc., which you plan to discuss with stakeholders, so they review them in advance and are better prepared for the meeting.
# Meeting Notes
TEXT in **_bold_** **_italic orange (_****_including links in_** **_light blue_****_)_** is meant to be adopted by each project.
## Meeting Title
#### DATE
**_yyyy/mm/dd_**
#### **ATTENDEES**
**_Name Surname_**
#### **GOALS**
**_Short description of meeting purpose_**
| **ITEM** | **NOTES** |
| ---| --- |
| **_1st discussion item_** | **_Short summary of discussion outcomes_** |
| **_2nd discussion item_** | **_Short summary of discussion outcomes_** |
#### **ACTION ITEMS**
* **_Action item, Responsible person, due date_****.**
# Escalation Process
# Escalation Process
### **MM/DD-MM/DD**
TEXT in **_bold_** **_italic orange (_****_including links in_** **_light blue_****_)_** is meant to be adopted by each project.
### **Issue levels:**
* **Cooperation** - unresolved question or challenge, which impacts cooperation between project stakeholders.
* **Project** - unresolved question or challenge, which impacts overall project performance.
* **Product** \- unresolved question or challenge, related to the product, which impacts overall project performance.
### **Escalation grounding rules:**
* Issues should be resolved on the level they originated. In case some issues can not be resolved on the same level, they are escalated to a higher level within the project hierarchy.
* The project manager has overall responsibility for driving, participating, and managing the overall issue resolution and escalation process.
List responsible persons of the process in the below table. Make sure all of them are listed in the [**Stakeholders register**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7482) as well.
| **ISSUE LEVEL** | **CLIENT** | **DEVCOM** |
| ---| ---| --- |
| **_e.g. Project, Product, Strategic_** | **_First and Last Name, Position (Role)_** | **_First and Last Name, Position (Role)_** |
# Onion Diagram
This diagram is used to identify stakeholders involved in the project. It helps to determine which stakeholders will directly interact with a system or process and those outside the organization to ensure that we won't miss any important stakeholder group.
To draw the diagram you need to identify the following categories of stakeholders:
**Layer 1:** Stakeholders, which are closely involved in the creation of the product, system, or process (our project team). Stakeholders may include the project manager, software developer, business analyst, product owner, etc.
**Layer 2:** Stakeholders whose work changes when the solution is defined. For example, end-users.
**Layer 3:** Sponsors, executives, and subject matter experts who interact closely with the system.
**Layer 4:** External Stakeholders such as regulators, government, suppliers, and the like.
You may use a Lucidchart [Template](https://www.lucidchart.com/pages/templates/stakeholder-onion-diagram-example) to make this diagram.
See the example below:
 
# Power/Interest Grid
Power/Interest Grid is a stakeholder prioritization technique used for Stakeholder management activity.
As a project evolves, more stakeholders are engaged in project activities. You may now have a list of people and organizations that are affected by your work. Some of these may have the power either to block that work or to advance it. Some may be interested in what you are doing, while others may not care, so you need to work out who you need to prioritize.
Power .png)
# Roles and Permissions Matrix
Roles and Permissions Matrices are grids that define all of the possible user roles, system operations, and the specific permissions on those operations by role. It is an easy way to keep this information in one place
## Template
[https://docs.google.com/spreadsheets/d/1I4Ay2vq58wxB4W-b68BRo5ilS3DOhaCfYmU-9COPqZU/edit?usp=sharing](https://docs.google.com/spreadsheets/d/1I4Ay2vq58wxB4W-b68BRo5ilS3DOhaCfYmU-9COPqZU/edit?usp=sharing)
# Personas
A persona can be defined as the illustration of the activities performed by a group of users who have similar motivations, behaviors, and goals.
Business analysts can employ the use of personas for bringing requirements to life, thereby leading to empathetic designs.
From the onset of a project, personas should be created early by design teams (BAs inclusive) to affirm their opinions about users and achieve a user-centered design.
Example of personas for an online employee training system using augmented reality (AR)
[https://docs.google.com/presentation/d/1s0Wcv8xX107KbCsoqotuF0Ns6SLtbdqgrieLdn09GJk/edit?usp=sharing](https://docs.google.com/presentation/d/1s0Wcv8xX107KbCsoqotuF0Ns6SLtbdqgrieLdn09GJk/edit?usp=sharing)
# Benchmarking and Market Analysis
Market research is a helpful tool to provide a business with insights before entering a new market, launching a new product or service, or just making a better business decision for the given period. **Note:** creating in-depth Market research is an iterative process.
# **Objective**
Usually, benchmarking and market analysis encompass more than one objective:
1. Gain a better understanding of a client's business and expand cooperation by uncovering the opportunities they might pursue with our help.
2. Understand the company's current state and define improvement areas (ex., optimization of business processes, implementation of new business capabilities)
3. Conduct competitors analysis to:
1. Understand the client's position in the market;
2. List competitors and their differentiators;
3. Identify strengths and weaknesses, define threats and opportunities of the company;
4. Help define the strategy for further product development.
4. Uncover industry trends to:
1. Discover the best performance indicators in the market/segment
2. Give recommendations on whether to consider entering a particular market.
3. Analyze what products/services can be offered.
4. Look for potential areas to invest in.
## When to do it?
* New product or service
* The new use case for an existing product
* Sales support
* New regulations
* New tech trends
* Competition
# **Step-by-step Guide**
1. **Determine the purpose of the research.**
1. Identify the research problem or the object of the analysis.
2. Specify the deliverables of the research, in particular, what types of outcomes are expected, timelines and stakeholders.
3. Find out to whom the research results should be presented.
2. **Plan the research.**
1. Plan the approach (what data needs to be collected and analyzed, what sources will be used to collect the data). The most frequently used types of sources for the research are:
1. Public sources
2. Commercial sources
3. Internal sources
4. Customer surveys
5. Interviews
6. Focus groups
7. Observation
2. Decompose the research into tasks and plan the team composition.
3. Estimate the research, and validate the plan and estimates with the requestor of the research.
3. **Collect the data according to the established plan**. This step may include the following:
1. Gather information on the industry-leading companies and their performance
2. Outline the current state of the market like the size, value, and volume
3. Investigate industry trends and projected market growth
4. Make a list of all of your main competitors. To identify the competitors whose products or services offer an alternative to yours, determine which industry or industries you're willing to step into:
1. Review the [G2 Grid Report](https://research.g2.com/market-reports) and/or [Gartner Magic Quadrant](https://www.gartner.com/en/research/methodologies/magic-quadrants-research) if available for your industry.
2. Download an existing market report. Companies like [Forrester](https://go.forrester.com/research/) and [Gartner](https://www.gartner.com/en/products/special-reports) offer free and paid market research annually on the vendors leading their industry. You may also consider such companies as GFK, PwC, McKinsey, IDC, KPMG. Also, the [Market research](https://www.marketresearch.com/browse/) source offers reports from many publishers. You may also review [IDG](https://www.igd.com/research/) research.
3. Search using social media, such as Facebook and LinkedIn.
4. Use platforms for finding business information about private and public companies ([Crunchbase](https://www.crunchbase.com/), [Owler](https://www.owler.com/), and [Zoominfo](https://www.zoominfo.com/)).
5. Consider user feedback: try to gain as much as possible from your competitor's users' feedback via Google research – blogs, forums, app store comments, comments on G2, Linkedin, etc.
5. Review online and offline sources:
1. Company's website
2. Official annual financial reports – for all public companies, the official reports are mandatory. There you can find not only financial information but technology trends the organizations are planning to follow in the upcoming year.
3. Government reports and studies - in developed countries, national institutions hold vast amounts of data.
4. Trade or industry-specific journals, magazines, and newspapers
5. Television and radio
6. Academic papers and educational resources
7. Online blogs, articles (TechCrunch, The Verge), and case studies
8. Competitors' demos:
1. Always check the legal aspects first.
2. Make sure you are in no violation of any policies.
3. See what your competitors emphasize – they will show the best of their products during the demo.
4. Prepare questions that answer your need but could not find on their website or Google.
4. **Analyze data.** This step may include the following:
1. Determine how your company/product relates to the benchmark of the leading company/product on the market
1. The [Competitors' Features Analysis](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-29861) may be of great help here
2. Identify the performance gaps and their possible root causes. Come up with recommendations about specific actions to mitigate the detected weaknesses
3. Provide a forecast of the market developments and think of other valuable insights for your business.
5. **Summarize your findings.** Make an executive summary of your findings. Generate a report based on your analysis. The recommendations should be made concerning the research goal.
6. **Put your analysis into action**. Communicate the research outcomes to the requestor of the research. Highlight your recommendations and future trends (if any). Collect and analyze feedback from the requestor concerning the research process and cooperation. Validate whether the subject of the research is covered sufficiently.
## How to craft your market research?
* Create a nice appealing market research – simple but professional language, visually pleasing, easy to read;
* Always add conclusions/key findings either in each main chapter or at the end;
* List the sources you have used – either at each slide or with a legend at the end;
* Use as much data as possible;
* Try to separate the different topics visually;
* Add backup slides – leave the main content on the slides; additional relevant information and calculations supporting the conclusions can be inserted at the end;
* Logically organize your data so it's easily understandable;
* Do spellcheck (use Grammarly);
* Check fonts and sizes;
* Name the worksheets, so it is easy to understand what's inside.
# Competitors Features Analysis
**Purpose:** Comparing product features of different products will give you an understanding of where your product stands compared to others – what features are the product's strong areas and differentiators, and what are the gaps and opportunities for improvements?
1. **Select competitors' products for comparison** \- search for software solutions similar to the analyzed product, and make a list of 10-25 products. Resources like Capterra, Gartner Magic Quadrant, and Owler can be used for that.
2. **Define the list of features for comparison**
3. If available, interview the subject-matter-expert (SME) of the analyzed product, and request a demo to decompose the product into the list of features. Otherwise, research competitors' websites and advertising materials to get the features they offer.
4. take 3-5 most promising competitors' products and complement the list of features with meaningful features not present in the analyzed product.
5. get approval for the list of features from the research requestor.
3. **Create a matrix** by listing features in the rows and competitors' products in the columns, including analyzed products as a baseline (see below)
1. **Analyze** all available public materials on competitors' products to determine features. Put the following:
2. 1 if the product has such a feature
3. leave empty if the product doesn't have it, or there is no information regarding this feature in public resources
4. 0,5 if the feature is mentioned in product marketing materials but with a bit different functionality or other specifics
2. **Calculate** results by summing up each row and dividing the sum by the total number of competitors' products.
3. **Interpret** results using the following approach:
|
**Feature is available**
|
**Feature positioning**
|
**Recommendation**
|
| ---| ---| --- |
|
**Competitors Products**
|
**Analyzed Product**
|
| 75-100% | yes | Basic | Keep |
| 50-74% | yes | Strong area | Improve |
| 25-49% | yes | Differentiator | Enhance |
| <50% | no or limited | Opportunity | Develop |
| \>50% | no or limited | Gap | Develop |
**Note** that the threshold values may vary depending on project and product specifics. Agree on valuesRrr with the research requestor at the beginning.
# Software Requirements Specification
**Template**
Software Requirements Specification (SRS) is the specification for a particular software product (or for a specific release, module, or component of such product).
An SRS describes all the capabilities a product must have in order to fulfill the business, stakeholder, and user needs. It defines the inputs, outputs, functions, and attributes of the system, as well as the attributes of the system environment.
[https://docs.google.com/document/d/1xoVO-t103zA4xS0ZeUnlYMkM7kslKwFAC38AaH141fs/edit?usp=sharing](https://docs.google.com/document/d/1xoVO-t103zA4xS0ZeUnlYMkM7kslKwFAC38AaH141fs/edit?usp=sharing)
# Requirements elicitation
Presale is a set of activities taken before a new customer or new project for the existing customer is acquired. A detailed description of the process can be found [**_here._**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5728)
# What Questions To Ask
## **How requirements questions**
* How will you use this feature?
* Is this feature a process, and if so, what are the steps? Or, what questions can I ask to ascertain the steps?
* How might we meet this business need?
* How might we think about this feature a bit differently?
* How will we know this is complete?
## **Where requirements questions**
* Where does the process start?
* Where would the user access this feature?
* Where would the user be located physically when using this feature?
* Where would the results be visible?
## **When requirements questions**
* When will this feature be used?
* When do you need to know about…?
* When will the feature fail?
* When will we be ready to start?
## **Who requirements questions**
* Who will use this feature?
* Who will deliver the inputs for the feature?
* Who will receive the outputs of the feature?
* Who will learn about the results of someone using this feature?
* Who can I ask to learn more about this?
## **What requirements questions**
* What do I know about this feature?
* Or, what assumptions am I making about this feature that I need to confirm?
* What does this feature need to do?
* What is the end result of doing this?
* What are the pieces of this feature?
* What needs to happen next?
* What must happen before?
* What if….? Think of all the alternative scenarios and ask questions about what should happen if those scenarios are true.
* What needs to be tracked?
## **Why requirements questions**
Why questions are great wrap-up questions as they help confirm that the requirements you just elicited map back to a need you identified when you scoped the project.
* Is there any other way to accomplish this?
* Does this feature meet the business need and solve the problem we’re trying to solve?
## Final deliverables for the presale
* Proposal
* High-level Estimates
* Tech stack + architecture
* Team
# Templates
* [**Vision and Scope Document**](https://docs.google.com/document/d/1yMqfEtxApXiTHRlQbnlMcZo0ILFU-SXzUpxlZ4w7NWM/edit)
* [**Requirements Management Plan**](https://docs.google.com/document/d/176TBxNcRVFfLlbrlnp_AN0HFlx4ET9yGteXY64XXk_Q/edit)
* [**Requirements Change Register**](https://docs.google.com/spreadsheets/d/1AIa0dwtPicggHrHXVxNDfFCvyeVRoxj8rWcrYSzOqEo/edit#gid=0)
* [**Communication Plan**](https://docs.google.com/document/d/1hevTXXKRuQ4KhWHmvn-Z52VyZkVpUiHwPuAvIOMPplU/edit#heading=h.cw08c9qbktbl)
* [**Software Requirements Specification**](https://docs.google.com/document/d/1xoVO-t103zA4xS0ZeUnlYMkM7kslKwFAC38AaH141fs/edit#)
# Discovery Phase Template
Please check the [**General Guidelines**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4441) for more information.
TEXT in **_bold_** **_italic orange (_****_including links in_** **_light blue_****_)_** is meant to be adopted by each project.
# Guideline
The team should go through the processes by following the pattern above. To shed light on the individual involvement, there is a detailed plan of how the discovery phase should be properly held:
1. A call with the client to understand the business need:
1. The main idea;
2. Business case;
3. Problem to solve;
4. Tools/features.
Time: **_90 min_**.
Team to participate: Client, BA, UX/UI, Tech Lead.
2. Discuss the main idea behind the goal. All team members discuss the idea from different points of view.
Time: **_2 d_**.
Team to participate: BA, UX/UI, Tech Lead.
3. Research. At this level, BA conducts research on competitors, analyzes their core functionality, and prepares a list of features designed to solve the problem considering the current need.
Time: **_10 d_**.
Team to participate: BA, UX/UI.
4. Discuss the key features to be included in MVP. The rest of the features are planned for further releases.
Time: **_1 d_**.
Team to participate: BA, UX/UI, Tech Lead.
5. A call with the client to agree on the MVP features.
Time: **_90 min_**.
Team to participate: Client, BA, UX/UI, Tech Lead.
6. Preparing wireframes.
Time: **_5 d_**.
Team to participate: BA, UX/UI.
7. Prototyping the idea with predefined core functionality.
Time: **_5 d_**.
Team to participate: UX/UI.
8. Testing the prototype involving end-users.
Time: from **_5 d_**.
Team to participate: Client, end-users.
At this level, the feedback is collected, and any rework is handled to match the user's expectations.
9. Final discussion with a client about whether the solution is missing anything or not.
Time: **_120 min_**.
Team to participate: BA, UX/UI, Tech Lead.
10. Tech team decision. At this level, the tech stack and development team squad are defined. The project schedule is to be planned and developed next.
Time: **_5 d_**.
Team to participate: BA, Tech Lead, developers.
11. Summary of the discovery phase. Preparing the final plan for the whole project development, including budget, scope, time, methodology, and recommendation of next steps.
Time: **_1 d_**.
Team to participate: Client, BA.
_NOTE: Any changes may affect the development time._
# Example
The team should go through the processes by following the pattern above. To shed light on the individual involvement, there is a detailed plan of how the discovery phase should be properly held:
1. **A call with the Client to understand the business need.**
1. The main idea;
2. Business case;
3. The problem to solve;
4. Tools/features.
Time: 90 min.
Team to participate: Client, BA, UX/UI, Tech Lead.
Total billable time: 4.5 hours (BA 1.5 hours, Tech Lead 1.5 hours, UX/UI 1.5 hours)
2. **Discuss the main idea behind the goal**. All team members discuss the idea from different points of view.
Time: 2 hours.
Team to participate: BA, UX/UI, Tech Lead.
Total billable time: 6 hours (BA 2 hours, Tech Lead 2 hours, UX/UI 2 hours)
3. **Research and solution development.** At this level, BA conducts research on competitors, analyzes their core functionality, and prepares a list of features designed to solve the problem considering the current need. Technical research is held if applicable (Podio API).
Time: 10 days.
Team to participate: BA, Tech Lead.
Total billable time: 104-120 hours (BA 80 hours, Teach Lead 24-40 hours)
4. **Discuss the key features to be included in MVP**. The rest of the features are planned for further releases.
Time: 1 day.
Team to participate: BA, UX/UI, Tech Lead.
Total billable time: 24 hours (BA 8 hours, Teach Lead 8 hours, UI/UX 8 hours)
5. **A call with the client where we go through every feature and agree on it to the MVP development.**
Time: 4 hours.
Team to participate: Client, BA, UX/UI, Tech Lead.
Total billable time: 12 hours (BA 4 hours, Teach Lead 4 hours, UI/UX 4 hours)
6. **Preparing wireframes.** Depends on the scope of work and the level of detailed description (lo-fi or paper sketch).
Time: 4-15 days.
Team to participate: UX/UI.
Total billable time: 32-120 hours.
7. **Prototyping the idea with predefined core functionality**.
Time: 2 days.
Team to participate: UX/UI.
Total billable time: 16 hours.
8. **Testing the prototype involving end-users.** At this level, the feedback is collected, and any rework is handled to match the users' expectations.
Time: from 5 days. Team to participate: Client, end-users.
Total billable time: 0 hours.
9. **Final discussion with a client about whether the solution is missing anything or not.**
Team to participate: BA, UX/UI, Tech Lead.
Total billable time: 3 hours (BA 1 hour, Teach Lead 1 hour, UI/UX 1 hour)
10. **Technical analysis:**
* technologies stack: 4 hours;
* development team: 4 hours;
* time for development: 4 days;
Team to participate: BA, Tech Lead.
Total billable time: 80 hours (BA 40 hours, Teach Lead 40 hours)
11. **Summary of the discovery phase.** Preparing the final plan for the whole project development, including scope, time, budget, methodology, and recommendation for the next steps.
Time: 1 day.
Team to participate: Client, BA
Total billable time: 8 hours.
**Total Discovery Phase billable time: 289.5 - 393.5 hours.**
# Presale
**Presale** is a process of customer engagement carried out before the project starts. Presale may be transformed into a project or/and the [**Discovery phase**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4441) in a best-case scenario or may be closed due to disagreement between a customer and the company. In both cases, appropriate lessons learned should be recorded.
# Presale Process Steps
Each presale process should be recorded in DCM. Presale may be billable or non-billable depending on an agreement conducted by Presale Lead. A presale team is formed purposely for the particular presale. [**The team**](https://docs.google.com/spreadsheets/d/1q3PkSa_NKupq4RnH6JkR8lVBYKm5_uzwN2VjqSM3djo/edit#gid=0) usually includes a Presale Lead (usually a salesperson), [**Business Analyst (BA)**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7122)**_,_** PM, UI/UX Designer, and Tech Lead(s) of software development.
The pre-sale process consists of 8 consecutive steps.
## **1\. Gather preliminary requirements**
The preliminary requirements should be collected so that the appropriate level of proficiency can be provided during the next meeting. The main goal is to understand the business case and the high-level scope.
## **2\. Concept review**
At this stage, the presale team should be composed. Then, the business case and the high-level scope should be validated by the team from different perspectives. As a result, a user flow, questions, assumptions, and suggestions should be created for later discussion with the client.
## **3\. High-level features validation**
All the outcomes of step 2 should be discussed with the customer. Moreover, new requirements should be collected following the principle that “the more detailed requirements are collected now, the more accurate estimates will be provided”.
## **4\. Scope decomposition & estimates**
Based on the requirements elicited in previous steps, the scope should be decomposed by relevant directions: UI/UX design, DevOps, back-end development, front-end development, mobile development, quality assurance, management, etc. Afterward, time estimates should be provided by experts in directions.
## 5\. Define high-level risks
Common high-level risks have to be included in the estimates.
## **6\. Create a User flow**
It is relevant to give the customer something more than just a quantity of hours of the estimated time. High-level user flow (created by UI/UX Designer), as well as architectural design (provided by Tech Lead), may be good extra perks that may guide the customer through the idea of project implementation.
Also, if Devcom has similar projects in its portfolio, case study samples will support the intention.
## 7\. Present a Solution Vision
To present a short summary of the information gathered above, including business needs, in-scope and out-of-scope features supported with a visual representation of the requirements. The goal of this presentation is to get buy-in from the customer so that the project team can proceed with estimates and sell the solution to the customer.
## **8\. Hold lessons learned session**
Any presale may be lost or won (transformed into the [discovery phase](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-4441) or/and project). No matter what result was reached, the lessons learned should be discussed and recorded by the presale team. This information might be used in order to improve the presale process.
# **Presale Process Breakdown**
## **1\. Gather preliminary requirements**
* A new presale has to be created in DCM (by Presale Lead);
* Preliminary requirements have to be collected (including documents from a customer) (by Presale Lead, BA);
* The following techniques may be helpful in performing this action:
* **Document Analysis** - analyze existing client documents, websites, and other materials to understand the business background.
* **Interview** \- an interview with a client to learn about business needs, users, and needed features, which might help meet those business needs. Please check the list of [**_questions to ask._**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7122?block=block-f780f6a6-ce30-43c6-82e4-b80de66a85e9)
* **Market Analysis** - analyze the client's market to see potential customer segments, buying patterns, competition, competitors, etc.
* **Process Analysis** - analyze the existing business process to define where and what improvements might be needed. [**The business Process Model**](https://businessanalystmentor.com/business-process-modelling-the-basics/) might help with this.
* Initial meeting with the customer (by Presale Lead, BA).
## **2\. Concept review**
* According to customer requirements, the presale team (UI/UX Designer, Teach Lead(s)) has to be composed (by AM);
* All the team members should be added to the presale in DCM (by Presale Lead/AM);
* Requirements collected by BA and Presale Lead should be discussed with all the team members (by Presale Lead, BA, UI/UX Designer, Tech Lead(s));
* High-level user flows (mockups) should be created (by BA/UI/UX Designer);
* The high-level scope should be broken down into the form of screens/tasks (by UI/UX Designer) and technical feasibility (by Tech Lead) with the help of BA;
* As an outcome, the list of questions, suggestions, and assumptions should be recorded (by BA).
## **3\. High-level features validation**
* The second meeting with the customer aims to approve an understanding where all the results of the previous step have to be confirmed. The new detailed requirements must be collected and clarified (by BA).
* Where applicable, visualize user flow, interactions between system parts, and use cases ([**_activity diagrams_**](https://www.lucidchart.com/pages/uml-activity-diagram), [**_user journey_**](https://www.lucidchart.com/pages/examples/customer-journey-mapping-software), [**_sequence diagram_**](https://gitmind.com/sequence-diagram-tool.html), [**_use-case diagram_**](https://www.lucidchart.com/pages/uml-use-case-diagram)).
## **4\. Scope decomposition & estimates**
* In scope and out of scope, items should be defined. [**_Decomposition diagrams_**](https://www.dummies.com/article/business-careers-money/business/general-business/how-to-use-process-decomposition-diagrams-in-your-business-analysis-report-162462), [**_Context_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-8688) [**_diagrams_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-8688)_, and_ [**_Feature trees_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-8708) are commonly used for scope decomposition.
* Time estimates have to be provided by team members (a 3-point (optimistic, most likely, and pessimistic) estimate is recommended) (by UI/UX Designer, Tech Lead(s));
* Quality assurance and management estimates should be added (by AM);
* Total time estimate, project timeline, and cost estimates must be calculated. Moreover, team composition and assumptions have to be provided.
## 5\. Define high-level risks
* High-level risks have to be analyzed (keeping in mind integrations, refactoring, human factors, information from UI/UX Designer and Tech Lead(s), etc.) and added to the estimate in the form of hours (by AM, PM).
## **6\. Create a User flow**
* High-level user flow has to be created (by UI/UX Designer);
* High-level architectural design has to be created (by Tech Lead(s));
* If there are available case study samples, they should be attached (by Presale Lead).
## 7\. Present a Solution Vision
* Business background and Solution Opportunities
* Scope
* Visual representation of requirements (Diagrams, mockups, User flows)
* Out of Scope
* Technical design (if applicable)
### **Example**
[https://docs.google.com/presentation/d/1oeuLp7PbZ7bgf6mER\_fQ0XI4qrL\_RE\_Zqjl-18l5Hcc/edit?usp=sharing](https://docs.google.com/presentation/d/1oeuLp7PbZ7bgf6mER_fQ0XI4qrL_RE_Zqjl-18l5Hcc/edit?usp=sharing)
### Template
[https://docs.google.com/presentation/d/1yOe\_bdCM-UGQW1L8vnihnWtw07fhZ9nVycBgvKZ9Eug/edit#slide=id.p1](https://docs.google.com/presentation/d/1yOe_bdCM-UGQW1L8vnihnWtw07fhZ9nVycBgvKZ9Eug/edit#slide=id.p1)
## **8\. Hold lessons learned session**
The results of the presale should be discussed (by Presale Lead, BA, PM, UI/UX Designer, and Tech Lead(s)) and recorded in order to create valuable information for further pre-sales.
Depending on the size and complexity of the project, the Solution [**Vision and Scope Document**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7102) might complement the more detailed Presale Template presented below or be used separately to validate requirements and get an agreement on the in-scope/out-of-scope items so that the project team can make estimates.
# Sample Template
[https://docs.google.com/spreadsheets/d/1Pi0Nj8Ar90mf7CizFrCaru1G-eLV8zlNR7FT1N4Z-Wo/edit#gid=533587263](https://docs.google.com/spreadsheets/d/1Pi0Nj8Ar90mf7CizFrCaru1G-eLV8zlNR7FT1N4Z-Wo/edit#gid=533587263)
# Discovery Phase (Guidelines)
[Ukrainian version of this guideline](https://docs.google.com/document/d/1J98UU28f2gPKMgqFotiYWch-13KZAJnsYfX1Lk8EDTc/edit?usp=share_link)
**The Discovery phase** is a time-framed process to research the business need and identify the main objectives to create the best solution to fulfill that need. It encapsulates commercial viability, UX approach, technological complexity, usability features, and the work scope.
Find the [**Template here**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5321)
# Guideline
## Discovery team
* BA, Tech Lead - must-have
* Designer - if there is a focus on UX
* PM, Subject Matter Experts (Data Scientist, DevOps, etc.) if there is a specific request
* Sales representative, AM - to support and facilitate communication if needed.
## Deliverables
* Proposal
* Estimates
* Time
* Budget
* [**_Vision and Scope_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7102)
* Business requirements and success criteria
* User roles
* Features List
* Solution context ([Context diagram](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-8688))
* Wireframes
* Prototype
* Refined Architecture Vision
* Technologies stack
* Architecture diagram
* Development team
# Stages
The Discovery phase consists of three stages. Each of them has its outcome. However, all three are related and should follow one another.
## Discovery
The main point is to get acquainted with the target audience and define the problems they face, their needs and/or opportunities. Also, that includes market research and analysis of competitors.
As a result, we will get a strong understanding of making the product unique and profitable.
## Interpretation
All known features which are requested by the users are listed. After deep analysis depending on business needs, key features of the minimum viable product (MVP) will be offered for the first release with a subsequent improvement to satisfy the pickiest users.
The outcomes of this stage are product wireframes and a low-fidelity prototype.
## Ideation
In this final stage, the end-users test the prototype, followed by their feedback. That gives a clear picture of whether the current prototype is ready to begin development or still needs to be improved. Based on the expert opinion of the Team, the Tech Lead forms the stack of technologies, and others suggest the development team squad, including the level of expertise. According to the features list and team members' qualifications, one estimates the time and budget.
The Discovery phase is usually executed by:
* business analyst
* UI/UX designer and
* technical expert (Tech Lead).
Other [team members](https://docs.google.com/spreadsheets/d/1q3PkSa_NKupq4RnH6JkR8lVBYKm5_uzwN2VjqSM3djo/edit#gid=0) can be included depending on project needs and scale.
Figure 1. Discovery phase loop.
Figure 2. The process of finding clarity driven by uncertainty
# Preparation
## Preparation to Discovery
Prepare an agenda based on the research results and planned deliverables. Research may include but be not limited to learning the client's business model, competitors, market, company structure, business domain, and the main problems of this business domain. Knowledge of the issues common for particular business domains would be helpful, as they would intersect with the client's problems, enabling the Discovery team to hold more effective and professional discussions.
International companies such as Gartner, Forrester, and Deloitte often publish market research for different business domains so that they can be used as reliable sources of information.
## Prepare templates before the Discovery Phase
Key deliverables Templates
* [**_Vision and Scope_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7102) - the main deliverable from discovery.
* [**_Stakeholders register_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7482)_._
* [**_Communication plan_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7082)_._
* [**_Requirements management plan_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7062)_._
* [**_User stories_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7062), [**_use cases_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7682)_._
### Templates for BI projects
Discovery for BI projects may be guided using the following supporting materials for planning interviews with a Client, specifying requirements for BI reports, and planning project milestones
[https://drive.google.com/drive/folders/1lvtTd0vWOlyzN2ZMZmWimH4NfUfSIr3W?usp=sharing](https://drive.google.com/drive/folders/1lvtTd0vWOlyzN2ZMZmWimH4NfUfSIr3W?usp=sharing)
A project kick-off presentation may be found here
[https://docs.google.com/presentation/d/1b6OZcJi0sV1nZDLhM674LGoaD\_6QCVNDTC6WL-R21Ik/edit?usp=sharing](https://docs.google.com/presentation/d/1b6OZcJi0sV1nZDLhM674LGoaD_6QCVNDTC6WL-R21Ik/edit?usp=sharing)
# Example Of Discovery Flow
The team should go through the processes by following the pattern above. To shed light on the individual involvement, there is a detailed plan of how the discovery phase should be properly held:
1. **A call with the Client to understand the business need (Kick off).**
1. The main idea;
2. Business case;
3. The problem to solve;
4. Tools/features.
Time: 90 min.
Team to participate: Client, BA, UX/UI, Tech Lead.
Total billable time: 4.5 hours (BA 1.5 hours, Tech Lead 1.5 hours, UX/UI 1.5 hours)
2. **Discuss the main idea behind the goal**. All team members discuss the idea from different points of view.
Time: 2 hours.
Team to participate: BA, UX/UI, Tech Lead.
Total billable time: 6 hours (BA 2 hours, Tech Lead 2 hours, UX/UI 2 hours)
3. **Research and solution development.** At this level, BA conducts research on competitors, analyzes their core functionality, and prepares a list of features designed to solve the problem considering the current need. At this stage, Technical research is held by Tech Lead if applicable. BA usually performs the following tasks:
* Identifies and specifies key business processes. This may be done with the help of UML diagrams ([**_BPMN_**](https://businessanalystmentor.com/business-process-modelling-the-basics/)**_,_** [**_Flow-chart_**](https://www.lucidchart.com/pages/what-is-a-flowchart-tutorial)) or by simply documenting the learned business processes. Business processes are revealed with the help of client document analysis, interviews, and/or workshops.
* Identifies Users and Roles - defines critical use cases, and stakeholder requirements in relation to the key business processes.
* Defines solution context with the help of a [**_Context diagram_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-8688) to understand how many interfaces should be developed and whether there are any integrations in place, defines types of data, and its flow ([**_Data flow diagram_**](https://www.lucidchart.com/pages/data-flow-diagram) may be developed at this point).
* **Defines key** **features** designed to solve the problem considering the current need.
* Defines quality attributes (non-functional requirements) critical for a solution. See examples [here.](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7102?block=block-ea795500-ad7a-4955-8036-7be95c26bd2c)
Don't ask the client directly what quality attributes (performance, security) the solution should satisfy. Define options for them so they have options to choose from.
During the Discovery phase, it is essential to define standard rules for future communication and requirements for life circle management (RLCM). This information would be a background for the [**_Communication Plan_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7082) and [**_Requirements management plan_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7062).
In particular, it would be helpful to define how frequently we would communicate with a client and what communication channels to use.
Define the format for the requirements (user story, use case) and how they will be managed (check the [**_Requirements management plan_**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7062) for more details)
It is important to define the list of stakeholders needed from the client's side and agree with the client that they would be available for the discussion so that we can cover all the needed questions.
Time: 10 days.
Team to participate: BA, Tech Lead.
Total billable time: 104-120 hours (BA 80 hours, Teach Lead 24-40 hours)
4. **Discuss the key features to be included in MVP**. The rest of the features are planned for
further releases.
Time: 1 day.
Team to participate: BA, UX/UI, Tech Lead.
Total billable time: 24 hours (BA 8 hours, Teach Lead 8 hours, UI/UX 8 hours)
5. **A call with the client where we go through every feature and agree on it to the MVP**
**development.**
Time: 4 hours.
Team to participate: Client, BA, UX/UI, Tech Lead.
Total billable time: 12 hours (BA 4 hours, Teach Lead 4 hours, UI/UX 4 hours)
6. **Preparing wireframes.** Depends on the scope of work and the level of detailed description (lo-fi
or paper sketch).
Time: 4-15 days.
Team to participate: UX/UI.
Total billable time: 32-120 hours.
7. **Prototyping the idea with predefined core functionality**.
Time: 2 days.
Team to participate: UX/UI.
Total billable time: 16 hours.
8. **Testing the prototype involving end-users.** At this level, the feedback is collected, and any
rework is handled to match the users' expectations.
Time: from 5 days. Team to participate: Client, end-users.
Total billable time: 0 hours.
9\. **Final discussion with a client about whether the solution is missing anything.**
Team to participate: BA, UX/UI, Tech Lead.
Total billable time: 3 hours (BA 1 hour, Teach Lead 1 hour, UI/UX 1 hour)
10. **Technical analysis:**
* * technologies stack: 4 hours;
* development team: 4 hours;
* time for development: 4 days;
Team to participate: BA, Tech Lead.
Total billable time: 80 hours (BA 40 hours, Teach Lead 40 hours)
11\. **Summary of the discovery phase.** Preparing the final plan for the whole project development,
including scope, time, budget, methodology, and recommendation for the next steps.
Time: 1 day.
Team to participate: Client, BA
Total billable time: 8 hours.
**Total Discovery Phase billable time: 289.5 - 393.5 hours.**
_NOTE: Any changes may affect the development time._
# Documentation Guide
# Guidelines
No matter what kind of work you do, your team needs clear, up-to-date documentation to help all members stay informed, be more efficient, and communicate clearly. The best way to get documentation that works is to establish documentation standards, in particular, set Templates for standard documents used at the project.
Documentation standards are the rules that guide the creation and distribution of documents within your team or organization.
When developing documentation standards, many questions may arise: _What format should we use for a particular type of documentation? Where will our documentation live?_ This guide will help you to answer some of these questions.
## Purpose of documentation and templates
The standards you follow will vary depending on the type and purpose of the documentation you are creating. Here are a few common types you may consider:
### PMO documentation
For a project to go more smoothly, everyone involved needs to be on the same page and have a single source of truth that they can refer to at any time.
You may check the Templates for PM activities [here.](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5281)
### BA documentation
To ensure the client's business needs are captured correctly, the requirements are specified and managed at the appropriate level of detail, and all the needed information is stored and may be accessed by relevant stakeholders, the BA [templates](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-29601) may be helpful.
## Where to store the documentation
Depending on the Project's needs and available tools, the documentation may be stored in Google Drive, Confluence, Jira, and other platforms the client uses.
No matter where the documentation is stored, it is important that it follows common DevCom patterns.
### Presentations
If you create a presentation, regardless of the purpose, you should use this template as a starting point.
[https://docs.google.com/presentation/d/1vmAgMpfnPurPaDMQ4jOWZlHgeE2YqvT2E75n1QuApcE/edit#slide=id.p1](https://docs.google.com/presentation/d/1vmAgMpfnPurPaDMQ4jOWZlHgeE2YqvT2E75n1QuApcE/edit#slide=id.p1)
### Other Documentation Guidelines
In case you don't have a Template at hand, you may use the following recommendation regarding documentation creation:
1. Use the Title page, where appropriate.
1. Include the Devcom logo in the top right corner
2. Include Document title and Subtitle (where appropriate)
3. Include the Date (ex. August 3, 2016) and Document Version (ex. Version: 1.0)
2. Use Header, and include:
1. Name of the document, Name of the Project, page N
3. Use Footer, and include:
1. DevCom Consulting LLC, [http://devcom.com](http://devcom.com/)
4. Use the following guides for text formatting
| **ELEMENT** | **FONT, SIZE, STYLE** | **COLOR** |
| ---| ---| --- |
| Title | PT Sans, 36, Bold | black |
| Subtitle | PT Sans, 14, Bold | dark grey 3 |
| Heading 1 | PT Sans, 20, Bold | dark grey 4 |
| Heading 2 | PT Sans, 16, Bold | dark grey 4 |
| Heading 3 | PT Sans, 14, Bold | dark grey 4 |
| Heading 4 | PT Sans, 13 | dark grey 3 |
| Normal text | PT Sans, 12 | black |
| Header | PT Sans 8 | dark grey 3 |
| Footer | PT Sans 8 | dark grey 3 |
1. Always check spelling and punctuation. Use your Grammarly  account or contact your supervisor.
## Template
See the Communication Plan document as a sample.
[https://docs.google.com/document/d/1EYkgHTHMzM\_HgbvosupQ2QnouEzLM0iDs2yQq5E5BOQ/edit?usp=sharing](https://docs.google.com/document/d/1EYkgHTHMzM_HgbvosupQ2QnouEzLM0iDs2yQq5E5BOQ/edit?usp=sharing)
# BA Training Program
| **COMPETENCIES** |
**Senior BA**
|
**Middle BA**
|
**Junior BA**
|
**BA Student**
|
| ---| ---| ---| ---| --- |
| **NEEDS AND CONTEXT** | | | | |
|
(p.
Establishing the business requirements in Wiegers, 2013)
|
**Mandatory**
|
**Mandatory**
|
**Optional**
|
**Not required**
|
|
Vision and Scope
|
**Mandatory**
|
**Mandatory**
|
**Optional**
|
**Not required**
|
|
Requirements Classification Schema, p16 in BABOK v.3, 2015
Levels and types of requirements, p. 7. Wiegers, 2013
https://www.youtube.com/watch?v=W6xgXMLfqs4&t=120s
|
**Mandatory**
|
**Mandatory**
|
**Mandatory**
|
**Optional**
|
|
User Story
Use cases
Understanding user requirements p. 143, Wiegers, 2013
|
**Mandatory**
|
**Mandatory**
|
**Mandatory**
|
**Optional**
|
|
(
1.6 Business risks, 1.7.
Business assumptions and dependencies, p. 88 in Wiegers, 2013)
(Discovering business rules, p. 177 in Wiegers, 2013)
|
**Mandatory**
|
**Optional**
|
**Optional**
|
**Not required**
|
| **BA APPROACH PLANNING** | | | | |
|
Who is the customer?, p. 27 in Wiegers, 2013
|
**Mandatory**
|
**Mandatory**
|
**Optional**
|
**Optional**
|
|
Meetings Schedule
|
**Mandatory**
|
**Mandatory**
|
**Optional**
|
**Optional**
|
|
Requirements Management Plan
|
**Mandatory**
|
**Mandatory**
|
**Optional**
|
**Not required**
|
|
Communication plan
|
**Optional**
|
**Optional**
|
**Optional**
|
**Not required**
|
| **REQUIREMENTS ELICITATION** | | | | |
|
Agenda
|
**Mandatory**
|
**Mandatory**
|
**Mandatory**
|
**Mandatory**
|
|
Preparing for elicitation p. 130, Wiegers, 2013
|
**Mandatory**
|
**Mandatory**
|
**Mandatory**
|
**Optional**
|
|
Organizing and sharing the notes p. 134, Wiegers, 2013
|
**Mandatory**
|
**Mandatory**
|
**Mandatory**
|
**Optional**
|
| **STAKEHOLDER COLLABORATION** | | | | |
|
Resolving conflicting requirements p. 116, Wiegers, 2013
|
**Mandatory**
|
**Optional**
|
**Optional**
|
**Not required**
|
| **REQUIREMENTS ANALYSIS AND SPECIFICATION** | | | | |
|
Modeling the requirements p.222, Wiegers, 2013)
|
**Mandatory**
|
**Optional**
|
**Optional**
|
**Not required**
|
|
Functional Decomposition in Business Analysis
|
**Mandatory**
|
**Mandatory**
|
**Optional**
|
**Optional**
|
| **SCOPE DEFINITION** | | | | |
|
Keeping the scope in focus, p.97, Wiegers, 2013
|
**Mandatory**
|
**Mandatory**
|
**Optional**
|
**Not required**
|
|
Context diagram
Functional decomposition diagram
Use
case diagrams
|
**Mandatory**
|
**Optional**
|
**Not required**
|
**Not required**
|
| **REQUIREMENTS LIFECYCLE MANAGEMENT** | | | | |
|
First things first: Setting requirement priorities, p. 313. Wiegers, 2013
|
**Mandatory**
|
**Mandatory**
|
**Optional**
|
**Not required**
|
|
Change management procedure
|
**Mandatory**
|
**Mandatory**
|
**Optional**
|
**Not required**
|
|
(Change happens, p. 471. Wiegers, 2013
)
|
**Mandatory**
|
**Optional**
|
**Not required**
|
**Not required**
|
|
Reaching agreement on requirements, p.38, Wiegers, 2013
|
**Mandatory**
|
**Mandatory**
|
**Mandatory**
|
**Optional**
|
|
Links in the requirements chain, p. 491, Wiegers, 2013
|
**Mandatory**
|
**Mandatory**
|
**Mandatory**
|
**Optional**
|
|
Requirements reuse, p.351, Wiegers, 2013
|
**Optional**
|
**Optional**
|
**Optional**
|
**Not required**
|
| **SOLUTION EVALUATION** | | | | |
|
Solution Evaluation, p. 163, BABOK v.3, 2015
|
**Mandatory**
|
**Mandatory**
|
**Optional**
|
**Not required**
|
| **BA TOOLS & TECHNIQUES** | | | | |
| User Story
|
**Mandatory**
|
**Mandatory**
|
**Mandatory**
|
**Mandatory**
|
| Use case
|
**Mandatory**
|
**Mandatory**
|
**Optional**
|
**Optional**
|
| Use case diagram
|
**Mandatory**
|
**Mandatory**
|
**Optional**
|
**Optional**
|
| Given When Then Statement
|
**Mandatory**
|
**Mandatory**
|
**Optional**
|
**Optional**
|
| Agenda
|
**Mandatory**
|
**Mandatory**
|
**Mandatory**
|
**Mandatory**
|
| Requirements Management plan
|
**Mandatory**
|
**Mandatory**
|
**Optional**
|
**Not required**
|
| Communication plan
|
**Mandatory**
|
**Mandatory**
|
**Optional**
|
**Not required**
|
| Vision and Scope document
|
**Mandatory**
|
**Mandatory**
|
**Optional**
|
**Not required**
|
| Change Register
|
**Mandatory**
|
**Mandatory**
|
**Optional**
|
**Not required**
|
| Context diagram
|
**Mandatory**
|
**Optional**
|
**Not required**
|
**Not required**
|
|
(Data Flow and Context Diagrams, p. 160, Howard Podeswa, 2009)
|
**Mandatory**
|
**Optional**
|
**Not required**
|
**Not required**
|
| Data Dictionary
|
**Mandatory**
|
**Optional**
|
**Optional**
|
**Not required**
|
| Sequence diagram
|
**Mandatory**
|
**Optional**
|
**Not required**
|
**Not required**
|
| Activity diagram
|
**Mandatory**
|
**Optional**
|
**Not required**
|
**Not required**
|
|
Lists
Maps
Personas
|
**Mandatory**
|
**Optional**
|
**Not required**
|
**Not required**
|
| Power/Interest Grid
|
**Mandatory**
|
**Optional**
|
**Not required**
|
**Not required**
|
| RACI Matrix
|
**Mandatory**
|
**Optional**
|
**Optional**
|
**Not required**
|
| Roles and Permissions Matrix
here.
|
**Mandatory**
|
**Optional**
|
**Optional**
|
**Not required**
|
| Prioritization
|
**Mandatory**
|
**Optional**
|
**Optional**
|
**Not required**
|
| Story mapping
|
**Mandatory**
|
**Optional**
|
**Optional**
|
**Not required**
|
| Mind mapping
Video
|
**Optional**
|
**Optional**
|
**Optional**
|
**Not required**
|
| Flowchart
| | | | |
| Business process modeling (BPMN)
BPMN by example, Bizagi Suite, 2014
|
**Mandatory**
|
**Optional**
|
**Not required**
|
**Not required**
|
# Mentorship Plan
A mentorship plan is a personal development plan assigned to the Mentee.
Its aim is to outline the goals of the mentorship program and to organize the work of the mentor and mentee. Details on the mentorship program at Devcom can be found [here](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5648?block=block-f0fe6c18-8a4f-4fdb-8007-c4ac2f31a86c).
The below mentorship plan helps to identify the main goals and their value, as well as to determine deadlines for each of the actions. Mentor prepares a list of the goals, tasks, and action items based on the current need and goals of the mentee defined in the PDP. Each individual has his/her own, distinctive strengths and weaknesses, so a mentor has the right to add extra tasks if she/he sees this need.
| **ACTION ITEMS** | **POTENTIAL VALUE** | **STATUS** | **DUE DATE** | **NOTES** |
| ---| ---| ---| ---| --- |
|
self-assessment
| Helps to define the current level of coverage for BA tasks on a particular level of seniority. | _To-Do; In progress: Done; Won't Do; Blocked_ | MM/DD/YYYY |
|
|
| After completion of the self-assessment, the key areas for self-improvement will be defined, so we can cover them using a plan with recommended readings. | | | Areas are defined by a mentor. |
|
plan
| Helps to improve weak areas defined in the self-assessment. | | | |
|
audit
| Define existing BA processes on the current project and outline potential improvements. | | | An audit will be done with help of a mentor. |
|
| Practical training of BA skills plus improvement of project processes related to BA work. | | | |
|
| Practical training of BA skills plus improvement of project processes related to BA work | | | |
|
| | | |
|
| | | | | |
# BA Onboarding Plan
A business analyst must have certain skills and knowledge in eliciting, validating, and managing requirements. The complexity of tasks he/she may perform and the level of the requirements he/she works with depends on the level of seniority and accepted responsibilities. The knowledge areas and tasks are listed below in this document.
Other corporate information is stored on the [Intranet](https://sites.google.com/devcom.com/dcintranet/home?authuser=0).
# **BA Student**
The main responsibility of a BA Student is to learn the basic BA procedures and artifacts and to support senior BA or a PM with requirements management activities depending on the level of knowledge he/she currently has.
## **Needs and** Context
### **Must know**
* The purpose of a [User story](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7662) and when it is relevant to use it.
### **Nice to know**
* Understanding the different types of requirements and where they are [stored](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7062) in the particular project.
## **BA approach planning**
### **Must know**
* Understanding who are the project stakeholders and where this information is [stored](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7482).
* Understanding what meetings are held to gather and validate requirements and where to [find](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7862) them.
## **Requirements elicitation**
### **Nice to know**
* Take part in the requirements elicitation meeting and capture [details](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7882).
* Confirm elicited requirements with stakeholders and ask questions if needed (ex. by e-mail).
## **Requirements Analysis and Specification**
### **Nice to know**
* Know what components/features the current solution consists of and how they are organized (ex. Epics in Jira, pages in Confluence).
## **Requirements Lifecycle Management**
### **Nice to know**
* Know how the requirements are [managed](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7062) at the project - where they are stored, and how they are prioritized and approved.
* Know how the requirements are linked to each other (ex., user stories linked to the relevant epics, subtasks linked to the user stories, or other tasks).
## **BA Tools & Techniques**
### **Must know (utilize)**
* Write [User Stories](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7662)
* Prepare [Meeting Agenda](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3921?block=block-659d9c24-bba9-4775-835d-fc25466c3d27)
### Nice to know (understand when to use and/or utilize)
* Write [Use Case](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7682)
* Create [Use Case Diagram](https://online.visual-paradigm.com/diagrams/tutorials/use-case-diagram-tutorial/)
* Write [Given When Then Statement](https://www.agilealliance.org/glossary/gwt/#q=~(infinite~false~filters~(postType~(~'page~'post~'aa_book~'aa_event_session~'aa_experience_report~'aa_glossary~'aa_research_paper~'aa_video)~tags~(~'given*20when*20then))~searchTerm~'~sort~false~sortDirection~'asc~page~1)) (for acceptance criteria)
# **Junior BA**
A Junior BA knows essential tools and approaches used for requirements management and stakeholder collaboration and assists a senior BA or PM with gathering and managing requirements for separate solution components.
## **Needs and** Context
### **Must know**
* Understand the different types of requirements and where they are [stored](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7062) in the particular project.
* Create [User Stories](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7662) and link them to the relevant solution components.
### **Nice to know**
* Understand how to define the client’s business need for the project and capture it in the [Vision and Scope](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7102) document.
* Understand how to identify assumptions, constraints, business rules, and solution-related risks and capture them in the [Vision and Scope](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7102) document.
## **BA approach planning**
### **Must Know**
* Specify project stakeholders and keep up-to-date [Stakeholders register](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7482).
* Organize meetings to gather and validate requirements, and capture them in the [Meetings Schedule](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7862).
### **Nice to Know**
* Prepare and maintain [Requirements Management Plan](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7062).
* Prepare and maintain a [Communication plan](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7082) (if not already done by a PM).
## **Requirements elicitation**
### **Must know**
* Assist in preparing an [agenda](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3921?block=block-659d9c24-bba9-4775-835d-fc25466c3d27) before requirements elicitation meetings.
* Take part in the requirements elicitation meetings and capture [details](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7882).
* Send a follow-up letter to the relevant stakeholders to confirm details, ask questions, and/or share action items.
### **Nice to Know**
* Facilitate Requirements elicitation meetings
## **Stakeholder Collaboration**
### **Nice to Know**
* Identify and manage requirements conflicts - organize meetings with the relevant stakeholders to resolve those conflicts and remove blockers.
## **Requirements Analysis and Specification**
### **Must know**
* Model requirements using simple techniques ([Use Case diagram](https://online.visual-paradigm.com/diagrams/tutorials/use-case-diagram-tutorial/), [Flowchart](https://www.visual-paradigm.com/tutorials/flowchart-tutorial/)).
* [Decompose](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7542?block=block-eddbb8e4-ae97-408b-90a0-5cc07769b4d6) Features into smaller pieces (User Stories, Tasks).
## **Scope Definition**
### **Nice to Know**
* Define in and out-of-scope items for a feature or a solution component (ex. using a [Context diagram](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-8688)).
## **Requirements Lifecycle Management**
### **Must know**
* Support requirements traceability as per the [guide.](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-9927?block=block-c0b3fafc-c642-49ea-95d8-be380dbf1d84)
* Link relevant requirements to the features/solution components or test cases to user stories depending on the values and needs of a particular project.
### **Nice to know**
* Assist a Product Owner or other client representative in functional requirements prioritization providing necessary context (constraints, interdependencies, risks).
* Know how to identify requirements changes and document them according to the [Change management procedure](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7702).
* Obtain stakeholders' approval for the requirements.
* Adapt requirements Template and reuse them where possible (for example, requirements which repeat (password, log in, standard notifications, etc.)).
## **BA Tools & Techniques**
### **Must know (**utilize)
* Write [User Stories](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7662)
* Prepare [Meeting Agenda](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3921?block=block-659d9c24-bba9-4775-835d-fc25466c3d27)
* Create [Use Case Diagram](https://online.visual-paradigm.com/diagrams/tutorials/use-case-diagram-tutorial/)
* Create [Flowchart](https://www.visual-paradigm.com/tutorials/flowchart-tutorial/)
### **Nice to know** (understand when to use and/or utilize)
* Write [Use Case](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7682)
* Write [Given When Then Statement](https://www.agilealliance.org/glossary/gwt/#q=~(infinite~false~filters~(postType~(~'page~'post~'aa_book~'aa_event_session~'aa_experience_report~'aa_glossary~'aa_research_paper~'aa_video)~tags~(~'given*20when*20then))~searchTerm~'~sort~false~sortDirection~'asc~page~1)) (for acceptance criteria)
* Create and follow a [Requirements Management Plan](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7062)
* Create and follow a [Communication plan](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7082)
* Create [Vision and Scope document](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7102)
* Create and manage a [Change Register](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7742)
* Create [Context diagram](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-8688)
* Create [Data Dictionary](https://thebadoc.com/ba-techniques/f/defining-a-data-dictionary)
* Create [RACI Matrix](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7522)
* Create [Roles and Permissions Matrix](https://www.linkedin.com/pulse/business-analysis-technique-39-roles-permissions-matrix-kashani).
* Facilitate [Prioritization](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7542?block=block-99f9f9d7-e6f8-485a-8cd3-2b97fb2df1f4)
* Utilize [Story mapping](https://www.digite.com/agile/story-mapping/)
* Utilize [Mind mapping](https://www.businessanalyststoolkit.com/mind-mapping-for-problem-solving/#:~:text=Mind%20mapping%20is%20among%20the,rules%20to%20using%20mind%20maps.)
# **Middle BA**
Middle BA uses various BA tools and techniques, including visual models (diagrams, wireframes, matrices), works with particular solution features, and defines business requirements. On top of that, he/she manages communication with stakeholders on different levels and works with pre-sales/discovery activities.
## **Needs and Context**
### **Must know**
* Define different types of requirements for the project and create relevant artifacts to store them - [Vision and scope](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7102), [Product requirements](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5361).
* Define the client’s business need for the project and capture it in the [Vision and Scope](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7102) document.
### **Nice to know**
* Understand how to identify assumptions, constraints, business rules, and solution-related risks and capture them in the [Vision and Scope](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7102) document.
## **BA approach planning**
### **Must know**
* Identify project stakeholders and their attitudes ([Power/Interest Grid](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7482?block=block-26cb3284-f689-4732-af76-0594519d4394)) and specify them in the [Stakeholders register](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7482).
* Organize meetings to gather and validate requirements, and capture them in the [Meetings Schedule](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7862).
* Prepare and maintain [Requirements Management Plan](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7062).
* Prepare and maintain a [Communication plan](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7082) (if not already done by a PM).
## **Requirements elicitation**
### **Must know**
* Define the items to discuss and the requirements for elicitation meetings, gather all the needed questions, and capture this information in the [agenda](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3921?block=block-659d9c24-bba9-4775-835d-fc25466c3d27).
* Facilitate requirements elicitation meetings and capture [details](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7882).
* Prepare and send a follow-up letter to the relevant stakeholders to confirm details, ask questions, and/or share action items.
## **Stakeholder Collaboration**
### **Must Know**
* Identify and manage requirements conflicts - organize meetings with the relevant stakeholders to resolve those conflicts and remove blockers.
## **Requirements Analysis and Specification**
### **Must know**
* Model requirements using different techniques relevant to the particular case ([Use Case diagram](https://online.visual-paradigm.com/diagrams/tutorials/use-case-diagram-tutorial/), [Flowchart](https://www.visual-paradigm.com/tutorials/flowchart-tutorial/), [Sequence diagram](https://thebadoc.com/focus-group-discussion/f/sequence-diagrams-made-simple), [Activity diagram](https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-activity-diagram/), etc.).
* [Decompose](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7542?block=block-eddbb8e4-ae97-408b-90a0-5cc07769b4d6) the solution into smaller pieces (Features, User Stories, Tasks).
## **Scope Definition**
### **Must know**
* Define in and out-of-scope items for a feature or a solution component (ex. using a [Context diagram](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-8688), [Feature tree](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-8708)).
## **Requirements Lifecycle Management**
### **Must know**
* Support requirements traceability as per the [guide.](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-9927?block=block-c0b3fafc-c642-49ea-95d8-be380dbf1d84)
* Link relevant requirements to the features/solution components or test cases to user stories depending on the values and needs of a particular project.
* Facilitate functional requirements prioritization, providing necessary context (constraints, interdependencies, risks).
* Identify requirements changes and document them according to the [Change management procedure](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7702).
* Obtain stakeholders' approval for the requirements.
### **Nice to know**
* Assess the impact of the identified requirements changes, document and communicate changes and their impact to relevant stakeholders.
* Adapt requirements Template and reuse them where possible (for example, requirements which repeat (password, log in, standard notifications, etc.)).
## **BA Tools & Techniques**
### **Must know (utilize)**
* Write [User Stories](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7662)
* Write [Use Case](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7682)
* Prepare [Meeting Agenda](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3921?block=block-659d9c24-bba9-4775-835d-fc25466c3d27)
* Create [Use Case Diagram](https://online.visual-paradigm.com/diagrams/tutorials/use-case-diagram-tutorial/)
* Create [Flowchart](https://www.visual-paradigm.com/tutorials/flowchart-tutorial/)
* Write [Given When Then Statement](https://www.agilealliance.org/glossary/gwt/#q=~(infinite~false~filters~(postType~(~'page~'post~'aa_book~'aa_event_session~'aa_experience_report~'aa_glossary~'aa_research_paper~'aa_video)~tags~(~'given*20when*20then))~searchTerm~'~sort~false~sortDirection~'asc~page~1)) (for acceptance criteria)
* Create and follow a [Requirements Management Plan](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7062)
* Create and follow a [Communication plan](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7082)
* Create a [Vision and Scope document](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7102)
* Create and manage the [Change Register](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7742)
* Create [Context diagram](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-8688)
* Create [Sequence diagram](https://thebadoc.com/focus-group-discussion/f/sequence-diagrams-made-simple)
* Create [Activity diagram](https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-activity-diagram/)
* Create [Power/Interest Grid](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7482?block=block-26cb3284-f689-4732-af76-0594519d4394)
* Create [Roles and Permissions Matrix](https://www.linkedin.com/pulse/business-analysis-technique-39-roles-permissions-matrix-kashani).
* Facilitate [Prioritization](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7542?block=block-99f9f9d7-e6f8-485a-8cd3-2b97fb2df1f4)
### **Nice to know** (understand when to use and/or utilize)
* Create a Data flow diagram ([Data Flow and Context Diagrams, p. 160, Howard Podeswa, 2009)](https://drive.google.com/drive/folders/1ZjGq4GLqhuNdiJ66koNCvSWszgdZsDCc)
* Create Stakeholder [Lists](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7482), [Maps](https://miro.com/blog/stakeholder-mapping/), or [Personas](https://www.uxpin.com/studio/blog/the-practical-guide-to-empathy-map-creating-a-10-minute-persona/)
* Create [Data Dictionary](https://thebadoc.com/ba-techniques/f/defining-a-data-dictionary)
* Create [RACI Matrix](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7522)
* Create [Roles and Permissions Matrix](https://www.linkedin.com/pulse/business-analysis-technique-39-roles-permissions-matrix-kashani).
* Utilize [Story mapping](https://www.digite.com/agile/story-mapping/)
* Utilize [Mind mapping](https://www.businessanalyststoolkit.com/mind-mapping-for-problem-solving/#:~:text=Mind%20mapping%20is%20among%20the,rules%20to%20using%20mind%20maps.)
* Create [Business process models (BPMN)](https://businessanalystmentor.com/business-process-modelling-the-basics/)
# **Senior BA**
Senior BA defines the approach for BA tasks, actively collaborates with stakeholders to facilitate the requirements life-circle process, and mentors other BAs. He/she also manages possible requirements conflicts and their escalation; works with the overall solution, not just particular features; leads pre-sales/discovery activities.
## **Needs and Context**
### **Must know**
* Create relevant artifacts for different types of requirements for the project ([Vision and scope](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7102), [Product requirements](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-5361)), and define new templates and approaches where applicable.
* Work with a client to define a business need and rationale for the product. Analyze this information and provide suggestions on a possible solution where applicable. Capture this information in the [Vision and Scope](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7102) document.
* Identify assumptions, constraints, business rules, and solution-related risks and capture them in the [Vision and Scope](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7102) document.
* Manage solution-related [risks](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7022).
* [Train](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-9221) other BAs or people who perform a BA role on a project.
## **BA approach planning**
### **Must know**
* Plan the relevant BA approach for a new project - what tasks and artifacts to use.
* Identify project stakeholders and their attitudes ([Power/Interest Grid](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7482?block=block-26cb3284-f689-4732-af76-0594519d4394)) and specify them in the [Stakeholders register](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7482).
* Organize meetings to gather and validate requirements, and capture them in the [Meetings Schedule](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7862).
* Prepare and maintain [Requirements Management Plan](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7062).
* Prepare and maintain a [Communication plan](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7082) (if not already done by a PM).
## **Requirements elicitation**
### **Must know**
* Define the items to discuss at the requirements elicitation meetings, define relevant stakeholders to invite, gather all the needed questions and capture this information in the [agenda](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3921?block=block-659d9c24-bba9-4775-835d-fc25466c3d27).
* Facilitate requirements elicitation meetings, workshops, and capture [details](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7882).
* Prepare and send a follow-up letter to the relevant stakeholders to confirm details, ask questions, and/or share action items.
## **Stakeholder Collaboration**
### **Must Know**
* Identify and manage requirements conflicts - organize meetings with the relevant stakeholders to resolve those conflicts and remove blockers.
## **Requirements Analysis and Specification**
### **Must know**
* Model requirements using different techniques relevant to the particular case ([Use Case diagram](https://online.visual-paradigm.com/diagrams/tutorials/use-case-diagram-tutorial/), [Flowchart](https://www.visual-paradigm.com/tutorials/flowchart-tutorial/), [Sequence diagram](https://thebadoc.com/focus-group-discussion/f/sequence-diagrams-made-simple), [Activity diagram](https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-activity-diagram/), etc.).
* Model client’s business processes where applicable ([BPMN](https://businessanalystmentor.com/business-process-modelling-the-basics/)).
* [Decompose](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7542?block=block-eddbb8e4-ae97-408b-90a0-5cc07769b4d6) the solution into smaller pieces (Features, User Stories, Tasks).
* Prepare and manage a [Backlog](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7542) if this is not managed by PO.
## **Scope Definition**
### **Must know**
* Define in and out-of-scope items for a feature or a solution component ([Context diagram](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-8688), [Functional decomposition diagram](https://www.lucidchart.com/pages/templates/business-analysis/lucidchart-functional-decomposition-example), [Feature tree](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-8708), [Use case diagrams](https://online.visual-paradigm.com/diagrams/tutorials/use-case-diagram-tutorial/)).
## **Requirements Lifecycle Management**
### **Must know**
* Define an approach for tracing requirements depending on the values and needs of a particular project.
* Assist a Product Owner or other client representative in functional requirements prioritization.
* Identify requirements changes and document them according to the [Change management procedure](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7702).
* Assess the impact of the identified requirements changes, document and communicate changes and their impact to relevant stakeholders.
* Obtain stakeholders' approval for the requirements.
### **Nice to know**
* Adapt requirements Template and reuse them where possible (for example, requirements which repeat (password, log in, standard notifications, etc.)).
## **BA Tools & Techniques**
### **Must know (utilize)**
* Write [User Stories](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7662)
* Write [Use Case](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7682)
* Prepare [Meeting Agenda](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-3921?block=block-659d9c24-bba9-4775-835d-fc25466c3d27)
* Create [Use Case Diagram](https://online.visual-paradigm.com/diagrams/tutorials/use-case-diagram-tutorial/)
* Create [Flowchart](https://www.visual-paradigm.com/tutorials/flowchart-tutorial/)
* Write [Given When Then Statement](https://www.agilealliance.org/glossary/gwt/#q=~(infinite~false~filters~(postType~(~'page~'post~'aa_book~'aa_event_session~'aa_experience_report~'aa_glossary~'aa_research_paper~'aa_video)~tags~(~'given*20when*20then))~searchTerm~'~sort~false~sortDirection~'asc~page~1)) (for acceptance criteria)
* Create and follow a [Requirements Management](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7062) Plan
* Create and follow a [Communication plan](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7082)
* Create a [Vision and Scope document](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7102)
* Create and manage a [Change Register](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7742)
* Create [Context diagram](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-8688)
* Create [Sequence diagram](https://thebadoc.com/focus-group-discussion/f/sequence-diagrams-made-simple)
* Create [Activity diagram](https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-activity-diagram/)
* Create [Power/Interest Grid](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7482?block=block-26cb3284-f689-4732-af76-0594519d4394)
* Create [Roles and Permissions Matrix](https://www.linkedin.com/pulse/business-analysis-technique-39-roles-permissions-matrix-kashani).
* Facilitate [Prioritization](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7542?block=block-99f9f9d7-e6f8-485a-8cd3-2b97fb2df1f4)
* Create [Business process models (BPMN)](https://businessanalystmentor.com/business-process-modelling-the-basics/)
* Create a Data flow diagram ([Data Flow and Context Diagrams, p. 160, Howard Podeswa, 2009)](https://drive.google.com/drive/folders/1ZjGq4GLqhuNdiJ66koNCvSWszgdZsDCc)
* Create Stakeholder [Lists](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7482), [Maps](https://miro.com/blog/stakeholder-mapping/), or [Personas](https://www.uxpin.com/studio/blog/the-practical-guide-to-empathy-map-creating-a-10-minute-persona/)
* Create [Data Dictionary](https://thebadoc.com/ba-techniques/f/defining-a-data-dictionary)
* Create [RACI Matrix](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7522)
* Create [Roles and Permissions Matrix](https://www.linkedin.com/pulse/business-analysis-technique-39-roles-permissions-matrix-kashani).
* Facilitate [Prioritization](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7542?block=block-99f9f9d7-e6f8-485a-8cd3-2b97fb2df1f4)
* Utilize [Story mapping](https://www.digite.com/agile/story-mapping/)
### **Nice to know** (understand when to use and/or utilize)
* Utilize [Mind mapping](https://www.businessanalyststoolkit.com/mind-mapping-for-problem-solving/#:~:text=Mind%20mapping%20is%20among%20the,rules%20to%20using%20mind%20maps.)
# BA Service Ordering
# BA Services
BA office uses the best practices and methodologies defined by the Guide to the Business Analysis Body of Knowledge (BABOK® Guide) to help projects succeed by increasing the team's efficiency and customer satisfaction. The BA services include but are not limited to:
* **Audit of BA-related processes** at the project to ensure the requirements management flow is set and followed and communication with the client and the team is performed regularly and with the appropriate level of details.
* Based on the Audit outcomes - outline the recommended action items and the following support for their implementation. Service details can be found [**here.**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7042)
* **Evaluation of BA resources** at the project - assessing the level of knowledge of a particular employee performing a BA role at the project. Details on the evaluation can be found [**here.**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7162)
* Providing the recommendations for further development and training.
* **Mentoring** for employees performing a BA role at the project - to support employees in their desire to develop as BAs within a company.
* Assistance with [**Presale**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-7122) and [**Discovery**](https://app.clickup.com/8491693/v/dc/834nd-2241/834nd-9001) activities.
## The Process of Ordering
One can request BA services using the [**template**](https://docs.google.com/spreadsheets/d/1-moBUEaatg6ce95c_U6W_AqD8BgKZbgg7Au0N_TwFnQ/edit#gid=1776200419)**:**
1. The **Requester** has to fill out the details:
1. Resource type
2. Involvement (%)
3. Purpose
4. Start and End date (if known)
5. and notify the Approver using email and/or skype.
2. After the service was ordered, it had the status **Open**.
3. The **Approver** or other responsible person must reply no later than the next business day to notify about resource availability and further provision in the **Comment** section and set status **In Review**.
4. A service has a positive decision if it is **Approved**; otherwise, it can also be **Rejected** or put **On-Hold****.**
# Integration Testing
# Postman
# Performance Testing
# JMeter
# Test Managment Tools
# Zephyr
# TestRail
# Postman
# JMeter