PLAY BOOK

A project begins with the analysis of client requirements. Analysis of the requirements can be divided into the following stages:

1. Gathering and analyzing client requirements
2. Requirements documenting
3. Project estimation

Team members engaged in requirements analysis:

• Project Manager
• Sales Manager
• Designer
• TeamLead and the team of developers

Gathering and Analyzing Client Requirements

The stage of gathering and analyzing client requirements is key in the project development process. Project duration and quality will depend on how well this stage is performed.

Requirements are the specifications of what must be implemented. Requirements gathering involves close communication between all stakeholders, from the client to the PM.

Client requirements can be functional or non-functional. Functional requirements specify the behavior of the system, and they answer the question “What should the system do?” in certain situations. Non-functional requirements answer the question “How should the system work?” and describe what properties or characteristics it must have.

Despite the existence of many methods of gathering requirements in the PMBOK Guide, our company uses only the following methods:

• Questionnaires and surveys
• Interviews
• Documents analysis
• Brainstorming
• Prototyping

Requirements analysis helps avoid problems of ambiguity, incompleteness, and inconsistency across individual requirements. Software requirements should be well documented, realistic, testable and written with a level of detail sufficient for project development.

The Manager must have the following qualities for successful work in the “Collection and analysis of customer requirements” stage:

• Subject knowledge
• The ability to listen
• The ability to ask competent questions
• Skills for creating a comfortable communication environment
• The ability to observe
• Stress resistance
• The ability to analyze and process information
• The ability to solve problems and resolve conflicts
• The ability to work with a team
• Creativity

Requirements Documenting

After completion of the “Gathering and analyzing client requirements” stage, the Manager must ensure that all client requirements have been carefully analyzed and documented.

We call documented requirements in any form an RL (Requirements List).

In an ideal project management situation, we document requirements and prepare Requirements List ourselves. However, we often work with already existing Requirements Lists provided by clients.

Self-documenting of requirements calls for a special approach from the PM. It also requires skills, experience and time.

All documentation is prepared by the PM together with TeamLead/TechLead and development team, who also communicate with the client to arrange and confirm the finished material.

Since companies often use the project management methodology Agile adapted to our projects and clients (i.e. not in its original form), we apply the appropriate types of documentation requirements:

• SRS — Software Requirements Specification
• Features description in any form in a Word document
• Internal project specifications according to the company’s template

After client approval, prepared documentation is sent to the team for the estimation phase. Links to the documents, or the files themselves, must be present in a special section of the WIKI in Redmine, and they must be updated as needed by the Project Manager.

Project Estimation

After gathering and analyzing client requirements, we transfer documented data to the team of developers for estimation. The PM is responsible for the project estimation (quote), while the Developers and Designer are key contributors to the estimation.

Project estimation in Redmine is located in a special project called Quotes. We keep all calculations for estimations in a Google Sheet. This spreadsheet has a specific format, which has been developed internally by the company.

As a result of the developers’ work at this stage, the PM receives an XLS file with a detailed estimation of each project’s feature. The PM sends this file with the estimation to the client and discusses the quotes. At the conclusion of this discussion, the project’s financial estimate and an estimated timeline are decided.

Requirements are the specifications of the features to be implemented. Specified in the requirements are the functionality of the website or module; user properties; compatibility with operating systems and various devices; and a description of the behavior of the various elements of the project.

The purpose of the requirements analysis stage is to get as much information about the client and the specifics of the tasks; specify the project scope; assess risks; and form a project group responsible for a significant part of all future work.

While obtaining and analyzing client requirements, one should take into account all varieties of requirements and make sure that nothing critical is missed. Otherwise, estimations could contain errors, terms could be breached, clients could experience frustration, and deadlines could be violated. It is recommended to create a checklist for all types of requirements.

Types of Requirements

Functional requirements:

• Business requirements
• User requirements
• System requirements
• Functionality requirements

Non-functional requirements:

• Business rules
• External interfaces
• Quality requirements
• Development constraints

More About Functional Requirements

Business requirements. What the features being developed should do from the point of view of the business side. The word “business” in this context can be thought of as closely related to the word “customer.” Consider this example: a promotional site that is created to attract a particular audience to a certain company’s product.

User requirements. These requirements describe the goals and/or objectives of the website’s users, which should be easy for them to achieve or perform on the site. These requirements are often presented in the form of use cases. In other words, user requirements are what the user is able to do: register, view certain information, recalculate data according to a specific algorithm, etc.

System requirements. These characteristics describe both hardware requirements (such as type and frequency of CPU, amount of RAM, hard disk size) and software environment requirements (such as operating system, installed system components and services, etc.). Usually, such requirements are defined by the manufacturer or the author of the software.

Functionality requirements. These requirements define the functionality, or behavior, of a software system, and they should be outlined by developers based on the framework of the business requirements and in the context of user requirements. In other words, these requirements are what the developers will do to implement the user requirements.

More About Non-Functional Requirements

Business rules. These define why the system should work exactly as written. These requirements can be links to legislation or internal customer regulations, or they can involve various other factors.

External interfaces. These include not only user interfaces, but also protocols for interfacing with other systems, such as CRM systems or external databases.

Quality requirements. These requirements relate to issues of transparency, interaction with other systems, integrity, sustainability, etc. They include:

• usability
• performance
• maintainability
• reliability
• interfaces
• scalability
• user and software interfaces

Development constraints. The three most common constraints on the project are duration, cost and quality, which are known as the “triple constraints.” Usually, when planning a project, the requirements for two of these three constraints can be met. For example, a project can be done quickly and efficiently, but it may be expensive. A project can be inexpensive and high-quality, but it may be a long-term project. If the client wants results quickly and inexpensively, then quality may suffer.

Input data:

• Client’s ideas
• Client’s task
• The general vision of the project

Participants:

• Project Manager or Business analyst
• TeamLead and the team of developers
• Client and its representatives (stakeholders)

The result:

Gathered client requirements in the form of notes, audio recordings, mockups and/or UML models.

Requirements gathering. This is one of the most important stages of any web project, be it creating a website from scratch, designing a site or just carrying out support tasks. Before you start gathering requirements, it is necessary to identify all of the client’s interested parties (stakeholders), or those who will be using the website. The more accurate this list is, the more comprehensive the requirements will be. One of the keys to success in gathering requirements is having a clear understanding of who is who. It is critical to understand who makes decisions on the client side and who only assists in requirements gathering and provides additional information.

The PMBOK Guide (Project Management Body of Knowledge) identifies 11 techniques of requirements gathering:

1. Interviews
2. Focus groups
3. Facilitated workshops
4. Group creativity techniques, the most popular among which is brainstormi ng;
5. Group decision-making techniques
6. Questionnaires and surveys
7. Observations
8. Prototypes
9. Benchmarking
10. Context diagrams
11. Document analysis

We mainly use the following methods: Questionnaires and Surveys, Interviews, Document Analysis, Brainstorming, Prototypes.

More About Several Methods We Use

Questionnaires

This method requires preparing a questionnaire (forms, briefs), which may contain open-ended questions (which require respondents to formulate their own answers) and closed-ended questions (which require respondents to select an answer from a list).

The survey is used to confirm or refine previously formulated requirements and to choose options for solutions.

What may be the most famous example of a survey for these purposes is the web development brief. This is a questionnaire containing a list of basic requirements and information about the future website.

Interviews

This method involves conducting negotiations with the client, either in person or by phone or Skype calls.

You must ask open-ended questions to gain information and ask closed-ended questions to confirm or refute certain versions of the requirements.

This method is used mainly to obtain information on a particular topic and/or to refine already existing requirements.

Before the interview, you must prepare by creating a list of questions that will enable you to conduct a preliminary analysis of previously gathered data from the client. You must also study the profile of the contact person on LinkedIn, if possible. Ideally, all conversations should be recorded (using a service such as Uberconference). Regardless of whether or not the conversation can be recorded, clients should be sent a brief summary afterwards. This can be in the form of an email with a specific structure. This message must contain:

• the date and time of the meeting
• a list of participants
• a list of issues and solutions
• if possible, the date and time of the next meeting

Brainstorming

Brainstorming is the most commonly used method for obtaining requirements associated with new or poorly understood areas of the customer’s organization or their site’s functions.

While brainstorming, many ideas can be collected from various client representatives in the shortest amount time possible and at virtually no cost.

During brainstorming sessions, participants simply suggest any ideas they may have for solving a problem. Brainstorming can be carried out with the client and their representatives or within members of one team looking for solutions.

Combining techniques allows requirements gathering to be an efficient process and helps prevent instances in which requirements are missed.

Input data:

Gathered client requirements in the form of notes, audio recordings, mockups and/or UML models.

Participants:

• PM
• Developers
• TeamLead/TechLead
• Client

The result:

Requirements List (RS).

Before starting work, the PM must ensure that all client requirements are documented, after thorough analysis. We call documented requirements in any form an RL (Requirements List). Requirements documenting occurs before project Estimation.

1. In the reference variant for project management, we document requirements and prepare Requirements Lists ourselves. However, we often we also work with already existing Requirements Lists provided by the client.

Project principles based on the requirements:

• If project requirements are clear and cover most of the features (there exists an RL or a specification), we should adhere to consistent implementation of these requirements in order to draw up a complete plan and Timeline. The correct sequencing of tasks saves development time.
• If project requirements are unclear and there are many gaps in them, we should identify well-documented tasks that we understand best and work on them in small portions and on short schedules (Phase, Sprint, Batch), completing each stage with a demonstration to the client to make sure that we are going in the right direction. In order to complete the rest of the task, it is necessary to gather further requirements and integrate them into the work process along the way, making a new schedule for the next stage.
• If requirements are minimal or the project is in support, it is necessary to perform tasks sequentially, depending on the client’s priorities, if applicable. Scheduling is not needed.

Self-documentation of requirements calls for a special approach, skills, experience and time. The nuances of self-writing technical requirements are shown in detail below.

The types of requirements documentation used in our company are:

• SRS — Software Requirements Specification
• Features description in any form in a Word document

Available documentation should be kept easily accessible and updated as necessary. Most often, documentation is stored in a Word or Excel file in a Google Drive folder. Links to documents or files must be listed or attached in the appropriate section of the WIKI project in Redmine.

Read more about using each type below.

SRS — Software Requirements Specification

Software Requirements Specification is used primarily for documenting the requirements of large projects, such as creating a website from scratch. The basics of using this type of documentation are:

• Keep a history of RL versions. Version numbers, dates, and lists of changes should be documented. For large projects, requirements will be changing and supplemented constantly.
• Add a table of contents for quick and easy navigation. It is expected that content sections will be lengthy. We can add links to specific parts of the content to aid in navigating RL pages.
• The RL should be created by a TechLead of the project or team who possesses adequate English skills. This should be a team member at the standing of at least Project Manager.
• The RL should be available both to the client and to the internal team.
• The description of features should be extensive, and details should be clear and meticulously described.
• Along with a textual description, the RL may be supplemented by graphic materials, such as screenshots, charts, tables, mockups or design.

Features Description in Any Form in a Word Document

This type of requirements documentation is used most often for medium and small projects. Rarely is it used when creating a website from scratch; more often it is used for improvements of existing features. The starting material is a blank Word file in a shared Google Drive folder, where the features of the project are described in steps.

This kind of RL is made by the PM of the project.

What is described:

• the behavior of the elements,
• the relationships between entities in the pages/whole site,
• dynamic visual effect,
• the properties of a custom Cabinet or bucket,
• checkout work,
• user rights, etc.

Compared with SRS, this type of documentation is less extensive and less detailed.

Along with a textual description, an RL may be supplemented by graphic materials, such as screenshots, charts, tables, mockups or design. An RL should be available both to the client and to the team.

Regardless of whether the client sent the RL or we drafted it ourselves, the PM must prepare internal specifications of the project according to the accepted template. This document is used actively in developers’ and testers’ work processes. It is also possible to document all approved changes to the RL in this document.

This documentation relates more to the Development Planning stage and is one of the points on the Manager’s checklist when all requirements have been estimated and confirmed by the client and a budget and development team has been established.

The PM is responsible for creating the internal project documentation file according to a template.

Input data:

• The need to create a design
• Client’s ideas
• Mockups or wireframes (if available)

Participants:

• Project Manager
• Designer

The result:

• Mockups or wireframes (if needed)
• Design in PSD format

When the client says they needs a design:

• We should clarify that the client only wants to receive PSD files, not a working site. We should also specify who will be responsible for the layout and functionality of the finished design.
• If the client only needs a design, then we ask for examples of sites they like, stipulating a color scheme.
• If there is no specification, we will request the site structure page by page (mockups or wireframes) and the description for each individual page by units (i.e. what information will be present and where it should be placed).
• Our designer draws up the layouts of all pages in order to coordinate the proper placement of planned units on the site.
• We show the client the design by sending it to them page by page.

Project estimation is based on the results of the Analysis of client requirements and all documents collected by the PM. Estimation of the project actively involves the team made up of the PM, the TeamLead and the developers.

The evaluation stage of the project consists of 2 steps:

• Creating a Quote
• Preparing a Commercial Proposal (CP)

During the Creating a Quote step, the PM creates a task in Redmine, which is complemented by a detailed description and all files and information obtained from the client concerning the project or task. The team of developers that will work on the project carefully study the information together with the TeamLead. While discussing the details of the project, the developers come up with questions and suggestions concerning the features. All the major parts of the project are divided into smaller parts and are estimated by developers. Developers often provide a min-max plug.

As a result of the team’s work during the Creating a quote stage, the client receives an XLS file containing the tasks list and estimation of the performance of this task in hours. Having received this estimation, the client communicates with the PM about the estimation and forms the project budget expressed in hours.

After the client’s approval of the estimation, the PM has the option to prepare a Commercial Proposal.

A Commercial Proposal (CP) is a document based on a template that includes a description of the terms of the project as well as basic information about the company, showing the client the benefits of cooperation. A CP is made on company letterhead and sent to the client as a PDF file.

The main components of the CP:

• A project overview. This is a brief description of the project, its audience, and its purpose.
• The choice of platform and/or technical solutions. This is a description of what CMS/Framework will be used, what programming languages will be used, what the components will be, and which external databases will be used in the project.
• A description of the scope of work. The PM describes which services will be performed by the company and to what extent.
• OThe cost of project and terms of payment. We document all financial terms of cooperation with the client: project payment model; hourly rates; work stages and a price for performing each stage; terms of providing discounts; terms of payment; payment methods; and consequences of breaches.
• Support for post-launch of the project. These are the conditions for providing support in case of bug detection, server issues, enhanced functionality, etc.
• “About” section. This is a brief description of WEB4PRO, which describes our competitive advantages and provides useful facts for the client (company departments, programming languages used, services provided, etc.).
• Date.
• The Director’s stamp and signature.

When the specification is ready, and the estimate is approved by the client, the project enters the Planning and Development stage. This process can be divided into three main stages:

1. Project planning
2. Development of the project
3. Tech support

Employees engaged in the planning and development of the project are:

• Project Manager (PM)
• Designer
• TeamLead and the team of developers
• Tester
• Client
• CTO of the company

Coordination and decision-making; requests for access to files and folders; and organizational issues are resolved by default by the Leading Department Managers (or other employees of the company, if regulations specify).

Read more about each stage below.

Project Planning

Planning is one of the key stages of development. According to the PMBOK, “a project is successful if completed in accordance with approved criteria: scope, time, and quality,” and these criteria are laid out at the planning stage.

When planning, all the preparatory work is carried out before development. Infrastructure is created in the working environments of the project, technical support is verified, team meetings are conducted. Project planning is performed by the Project Manager.

Highlights of the planning:

• The PM should be guided by the checklist during project planning.
• The Timeline is the main tool used for allocating resources and evaluating the work scope. In addition, it helps monitor these factors.
• The primary environment of project infrastructure is Redmine and Bitbucket.

Communication between team members is mostly conducted in Skype, Slack, and emails. The primary project infrastructure environment — Redmine — is a task-tracking system. Each employee has access to Redmine, which is accessible both in a production environment and from any computer outside the office. The Redmine system is very versatile and flexible when it comes to settings, and the most important aspects of usage for the Manager are described in the Rules of Work with Redmine.

Opportunities within Redmine during project management:

• create tasks and monitor their implementation
• assess project risks
• calculate project efficiency
• keep important and necessary information in one place — the project WIKI
• connect external users to the project

Redmine is a very effective tool for PMs.

Development of the Project

Project development is the most important and crucial part of the project. This is a basic, long-term and critical stage of the lifecycle of the project for many reasons. Resource planning and timing are typically validated at this stage, and the client sees tangible results and the realization of their ideas. Critical force majeure events may also occur. Estimations are verified and teams are examined at this stage.

The main task of the PM at this stage is to monitor the team, timelines, resources, quality, costs and feedback from the client.

Development always starts with a team meeting, where the team discusses the nuances of the RL, confirms the tasks estimations and jointly determines the technical solutions and architecture. The participants also agree on the frequency of future meetings.

As a rule, the execution of the tasks begins after conducting this meeting. The PM is responsible for work surrounding Tasks and Phases.

A task is the smallest element of the functionality of the project. Tasks can be either related or unrelated. A phase is a set of tasks linked together logically and functionally, the implementation of which is tied to a specific deadline. Usually, we show the result of Phase execution to the client as an intermediate result of the project. The PM monitors the readiness of tasks daily, according to the Timeline, and thus the readiness of phases is also monitored.

Completed tasks and phases are subject to compulsory testing before being shown to the client. A special employee is appointed for testing — the software tester (QA). The tester interacts with the project according to its official instructions.

If we are working on a project on a fixed price model, it is important to adhere to the RL approved by the client in order to prevent issues that would result in changes to terms and payments. In the event of the presence of an additional task from the client, the ideal solution would be to move it to a separate phase and complete it after performing the pre-specified objectives. However, sometimes there are exceptions.

Before completing work on the second half of the project’s final phase, the PM has to complete various tasks. Namely, the PM must analyze the current project, the client’s history, their current needs and their potential future needs. The PM must also suggest improvements to the project.

The design phase is considered complete when all tasks from the RL have been performed to the proper standards within the agreed client deadlines and they have been confirmed and paid for by the client. After that, the project can be deployed to the client’s live server.

Obligatory tasks of the PM after project completion are:

1. To perform analysis after completion, to carry out a retrospective
2. To add the project to the company’s internal portfolio

Tech Support

Technical support (tech support) is a set of services aimed at maintaining the site, updating it and improving it.

Technical support in our company can be provided both to internal clients, for which we have made a site from scratch, and to external clients, who come to us with ready-made websites.

Technical Support includes the following:

• Technical website audit
• Website updates
• Support of site functionality
• Interaction with the hosting provider

Input data:

A list of prerequisite tasks to perform before the start of the project

Participants:

• Project Manager
• TeamLead and the team of the project

The result:

Documented evidence that all conditions are met for a successful start to the project.

Project principles based on the requirements:

• If project requirements are clear and cover most of the features (meaning there is an RL or a specification), we should adhere to consistent implementation of these requirements in order to draw up a complete plan and timeline. Correctly sequencing tasks saves time during the development phase.
• If project requirements are unclear and there are many gaps, we should identify well documented tasks that we understand best and work with them in small portions and on short schedules (Phase, Sprint, Batch), completing each stage with a demonstration to the client to make sure that we are going in the right direction. In order to complete the rest of the task, it is necessary to gather further requirements and to integrate them into the work process along the way, making a new schedule for the next stage.
• If requirements are minimal or the project is in support, tasks must be performed sequentially, depending on the client’s priorities, if applicable. Scheduling is not needed.

Checklist for project planning

1. Agree on the final team of developers, along with TeamLeads, using the Team Upload file.
2. Draw up a detailed Project Plan (Timeline) that divides the work into tasks for each project participant and delivers results on time.
3. After the TeamLeads and client approve the project plan, the PM and TeamLeads fill out the Upload file.
4. Create and fill out the internal documentation file, which is important for large projects (for example, those taking more than 100 hours) involving several departments.
5. Create a project in Redmine and transfer the task with the quote from the Quotes project to the new project.
6. Connect the team of developers, lead manager and tester to a project in Redmine.
7. Assign people to the appropriate roles.
8. Complete the project overview and, if necessary, add a description of the project and customer data. For example, if multiple clients are connected to the project, you need to specify what each is responsible for.
9. Fill out the WIKI page according to the standard.
10. Add the version in the project settings. The version name depends on the project specifics.
11. Add categories in the project settings (if necessary). The category name depends on the project specifics.
12. Add the client, if necessary.
13. Create a repository on Bitbucket to grant people the necessary levels of access. You must grant the engaged TeamLeads Admin rights.
14. Add tasks to the project. The requirements for tasks creation are described in a separate section.

Input data:

• Prepared project estimation, approved by the client
• Customer requirements and/or wishes concerning terms
• An appointed project team

Participants:

Project Manager

The result:

Completed Timeline with deadlines and a work plan for each team member. Established Project Checkpoints.

A timeline is a way of displaying a list of project events in chronological order, sometimes called a project artifact. It is typically a graphic design, featuring a long bar, representing time, with dates and events labeled on it.. (c) Wikipedia.

When planning the project, the PM draws up a detailed Project Plan (or Timeline), which includes the division of the work into tasks for each project participant and the distribution of these tasks according to a schedule. PMs can create Timelines both for live projects with milestones as well as for projects still at the quote stage. Usually, it is necessary for the client to know the project deadline before agreeing to work with us.

The work plan, divided into tasks and time spans, must be confirmed by TeamLeads, and the final terms must be confirmed by the client.

Specifics of creating the Timeline:

• The recommended amount of time for one task is no more than 8 hours so that it is easier to control the execution process. There are some tasks that are difficult to divide into smaller parts, and those require more careful and controlled execution.
• The developer’s maximum workload on the main project is six hours a day. The remaining two hours are left for feedback on other projects or tasks, quotes, force majeure and other unforeseen circumstances.
• For large projects (over 40 hours) tasks are divided into Phases or Milestones. There may be many factors influencing the duration of the phase, such as client requirements, project specifics, total scope of work, developers’ workloads, etc. Consequently, the duration of phases for each project may differ. Each phase should take no more than 3-4 weeks.
• Established Project Checkpoints (CP) for the Manager and for the client are intermediate dates that will allow you to check the percentage of work executed and be aware of deviations from the plan.

PM Checkpoints are marked in yellow on the Timeline. When passing a PM’s CP, if less than 80% of the tasks have been performed by developers, then the CP color should be changed to red. If 80% or more of the tasks have been completed, the CP should be changed to green. Two red CPs is a bad sign. It signifies a high probability that the project will fail and urgent measures will be needed to save it.

Where quote and timing are concerned, for the successful implementation of the project, you need to clearly understand what stage and in what state the project is at any given moment. One of the main responsibilities of the PM is to update the Timeline in a timely manner.

The Timeline also must be available to the team of developers working on the project, as well as to the client. Depending on the specifics of the project and its estimation, the Timeline may be created both in a shared file and in separate files for the developers and the client.

Input data:

• Project RL
• Arranged project infrastructure in Redmine
• Project Timeline
• Design (if applicable)

Participants:

• Project Manager
• TeamLeads of departments and developers
• Tester

The result:

• Established contacts in the project team (everyone in the team knows who is responsible for what);
• A list of possible risks;
• Variants of actions in case of obstacles;
• Well thought-out technical solutions;
• Answers to the questions that are needed to start work on the project.

Before starting the project, it is necessary to hold a meeting with all project participants. Goals of the meeting:

• get acquainted with the team (this is particularly important for large projects)
• discuss the nuances of the RL
• ask questions and get answers
• jointly define technical solutions and architecture
• agree on the frequency of meetings

The organizer of the meeting is the PM.

The participants are the developers, TeamLeads of teams, PM and tester.

Organization can be done through Google Calendar.

Before the meeting, the RL and design must be sent to everyone and it must be ensured that everyone has reviewed them before the meeting. At the meeting, you also need to have several copies of the printed RL and, if we are working with a design, printed design pages.

For large projects (more than 100 hours) meetings must occur periodically. Therefore, at the first meeting, you need to determine how often to meet and agree on the date of the next meeting.

As usual, after the meeting, the final list of issues and solutions that were discussed must be sent to all participants.

The following is a list of the main issues that should be discussed at the meeting. This list is not finalized and may be expanded upon depending on the project and the situation.

• Has full and sufficient information on the sprint or task been provided for developers?
• What are the team’s questions on the tasks in the current sprint?
• What is the status of all tasks at the time of the meeting? Each participant briefly updates the whole team so that everyone knows what is going on in the project.
• Are there any difficulties that would preclude the team from performing tasks within the prescribed period, and if so, what solutions should be implemented?
• What general comments or observations does the team have on the current progress or status of the project?

Input data:

• The project, in an active development stage
• Project Timeline

Participants:

• Project Manager
• Client
• TeamLeads and developers of the project

The result:

• No delays in project completion
• Reduction of risk of exceeding quotes
• Minimal losses in the case of exceeding quotes
• Good communication among project participants

The PM starts their day by checking their email and viewing each project by open tasks in Redmine. They should check:

• Statuses. First and foremost, they should pay attention to tasks with “Request” status. When the Manager detects a task with “Request” status, they should alert the client or, if the client is engaged in the project, remind them about the issues and send them links to the task. If the client has not updated the tasks and has not changed task statuses, the Manager changes the status to Feedback after checking.
  • If a task with “Feedback” status has not been updated for more than 1-2 days, we check the task’s deadline and remind the developer of it again, either by updating the task, sending an email or sending a Skype message.
  • If a task with “New” status has not been updated for more than 2-3 days, we first check the task’s due date. Further actions depend on the due date.
  • If a task with “Sent to Client” status has not been updated for more than 2-3 days, we remind the client about it.
• Tasks with due dates set for the current day or the next few days.
• Project Timeline. It is necessary to note the relevance of locally performed tasks that were confirmed by the client. Checkpoints should be monitored and noted in the plan. Take some actions depending on the results of monitoring (refer to the TeamLead or developer, check the task, etc.)
• Time spent on tasks. The developer notes in Redmine how much time has been spent and what percentage of the task has already been implemented each day. All time spent should be noted in Tasks.

Monitoring the readiness of phases

A few days before the completion of a phase, the PM checks the tasks within the phase and makes sure that everything is progressing according to plan. It is also necessary to make sure that the task for testing has been created and the Tester’s time is scheduled and noted in the upload file. Testing and bug fixing must be completed prior to the deadline of the phase.

The project PM informs the client of the readiness of the phase on the phase deadline or earlier and asks the client to check the status of issues reported and ask any remaining questions about them.

Monitoring techniques

Once a day, the PM goes to the developers for an update on task progress and asks if there are any problems or questions. If there are problems or questions, the PM notifies the TeamLead of them and asks them to check in and help as needed. For long projects, additional monitoring is carried out at established checkpoints (frequency — about once a week).

The tester must be incorporated into the working process at the planning stage of development to ensure that testing is part of the development process and is not left as one of the project’s final steps. Testers are engaged in working processes in three stages:

Stage 1: Preparatory (upon receiving a project).

The tester must be linked to the Quote Task before the start of testing. The tester examines the information about the project from the quote and refers to the PM if there are any questions.

Checklist for the preparatory process:

• Subject area (for example, online shop selling books).
• Target audience (the country for which the website will be developed, average age of potential users).
• The competition (if such information exists).
• At this stage, the PM must be asked when the tester can be brought into the project. Also, the tester must prepare a list of questions for further discussion of the project at the meeting with the team.

It’s crucial that the preparatory stage take no more than 5% of the total time set aside for testing.

Stage 2: Creation of the task for testing (upon completing one or more project tasks)

Necessary information for testers in the WIKI of the project:

• Links to the documentation with specifications (or any other project documentation);
• Passwords and access rules for all accounts needed for testing (the standard list of accesses as well as additional access to external resources required for testing, if needed);
• Design documentation (a description of any changes to design);
• The project’s development stage and scheduled release date;
• A link to the internal documentation that the PM writes up during the development of the project.

PM checklist for drafting a task for testing:

• Description of the task, noting which part of the project needs to be tested. Add the developer’s task as a Related Issue.
• Estimated time scheduled for testing in this task.
• Bug prioritization, noting which must be fixed first. For example, if the interface is not very important to the client at this stage, assign functionality bugs a high priority, and assign all other bugs a normal priority.
• The types of testing that must be applied to the project (functional, interface testing, localization, usability, compatibility, integration testing).

Functionality testing aims to test the feasibility of functional requirements. In other words, the tester needs to check that the designed software is able to complete the tasks for which it was created. The tester must also check if the software fulfills the needs of the customer or user. Each project will have unique functional testing due to the fact that each project’s specifications are unique. This type of testing is mandatory and should be applied to all tasks (with the possible exception of tasks on interface testing).

Usability testing is a method of testing aimed at establishing the developed project’s ease of use, understandability, and attractiveness to users. For new projects, this type of testing should be carried out by default (because usability is an integral part of quality). For projects involving updates to finished sites, we can only offer usability testing.

Localization testing is the process of testing localized versions of the website. It involves defining the list of supported languages; checking the correctness of the translation according to the topic of the website; checking the correctness of the translation of the user interface elements; verification of translation of system messages and errors; and verification of the help section and support documentation.

Compatibility testing checks that the product operates correctly in certain environments (the device and OS versions the client has requested).

Interface testing is testing aimed at checking the compliance of the implemented website interface and layout that were provided by the client. It is mandatory to confirm with the client whether or not the project must be pixel perfect.

Integration testing is the testing of a system consisting of two or more modules. The main objective of integration testing is to detect defects related to errors in the implementation of the interface interaction between modules.

The second step is to discuss with the PM the time needed for writing the test plan and test cases or checklists.

Stage 3: Discussion with developers (upon completion of one or more project tasks, just prior to the start of testing)

If it is difficult to communicate with the developers because of technical or linguistic reasons, these questions are answered by the PM.

Checklist of questions for the developer:

• Which components are completely ready, which are not, and which need further development? In the majority of cases, there is no sense in testing components that are not ready and will be further developed or redeveloped. They do not require much attention, but the tester should be aware of them.
• Are the placeholders used? Areas, where placeholders are used, should be taken into account when testing. Otherwise, time is spent on questions and bugs related to non-functioning buttons, and unimplemented features from the specifications are discussed.
• What bugs are currently known, and are they recorded in the bug-tracking system? Quite often, developers working on the project are aware of a certain number of bugs. Absolutely all known bugs should be recorded by our team in the bug-tracking system.

At the end of the third stage, QA starts the testing process.

Input data:

• Project RL
• Project Timeline
• Client’s new tasks, which are not included in the RL

Participants:

• Project Manager
• Client
• TeamLeads and developers of the project

The result:

• No chaotic situations
• A calm and relaxed client
• The ability to add to the team’s workload as quickly as possible

In the case of additional tasks from the client during the process of working on the project, the ideal solution would be to move them into a separate phase and perform them after performing pre-specified objectives.

The PM first estimates how critical the performance of additional tasks is in the framework of the current phase. If it is critical and the tasks are estimated to take no more than 1-2 hours, they may be added to the implementation of the current phase. The deadline phase is not likely to be violated, but you need to check and confirm this with the developer and/or TeamLead. If the new tasks are critical, and the estimation shows that they will affect the final deadline of the phase, then:

1. You need to report to the client about it and ask them to confirm the postponement.
2. After the confirmation, you need to make adjustments to the plan and create tasks in Redmine.
3. If it is very critical for the client to perform the new task and they do not want to shift the phase date, you should consider the option of removing from the phase one or more tasks of an equal number of work hours to the new task.

Keep in mind that if we insert a new task in the middle of the phase or project, the final deadline of the entire project will be shifted.

The estimation of new tasks is made by the PM, who:

1. Creates a task for a quote in the current project or subproject
2. Communicates questions and answers between the client and the programmer
3. Agrees on the deadlines and changes the Timeline if needed
4. Communicates the final information to the client (estimation, term, cost)
5. After confirmation of the project, schedules it according to the established processes

Input data:

• Project RL
• Project Timeline

Participants:

• Project Manager
• Client
• TeamLeads and developers of the project

The result:

• The ability to add to the team’s workload in the future
• The growth client’s trust and respect

Before completing work on the second half of the project’s final phase, the PM has to complete various tasks. Namely, the PM must analyze the current project, the client’s history, their current needs and their potential future needs. The PM must also suggest improvements to the project (for example, a mobile version, optimized page loading, a new method of payment, etc.).

This analysis is performed to find out the client’s additional needs that emerged while working on the project. Developers and TeamLeads may be engaged in the analysis. This must be done in advance (preferably 2-3 weeks before the end of the project) since a certain amount of time is spent on estimation, questions, approval of the budget and writing the RL.

Input data:

• Completed and tested project
• Customer confirmation of the transfer
• Client’s server access

Participants:

• Project Manager
• Client
• TeamLeads and developers of the project

The result:

A working site on a live client server.

After completion of all work on the project, we transfer the changes to the live client server. In the estimation file, this action is called “deployment to the production server.” To deploy the project, the PM creates a task for a developer, providing access to the live server, a description of the task and the nuances of transfer, if any (time limit for clients from other time zones, the conditions of database transfer, etc.) and domain name (if any).

The result will include a link to the client’s website. In addition, after the transfer, developers need to check internal links, availability of images, logo, favicon and the mobile site’s behavior.

Steps that must be taken before deploying the project are:

1. Requesting access to the client’s live server and checking for compatibility with the functionality of the website in advance (PHP version, necessary APIs). To achieve this, the PM creates a task in Redmine for the developer of the team.
2. Complete testing of the project to ensure that the completed work meets the specifications and solves client’s problems. The client must confirm that they are satisfied with the results.
3. Preparing a manual for managing new functionality through the Admin panel. Usually, if the project is divided into phases, we prepare a user manual for each phase. Before project delivery, we must ensure that the instruction for all previously completed phases is still relevant. If there were previously no instructions, they must be prepared from scratch.

Input data:

• The completed project approved by the client
• Statistics on hours spent
• Project estimation

Participants:

• Project Manager
• Client
• TeamLeads and developers of the project

The result:

• Google Doc with gathered feedbacks
• Conclusion after analysis
• A list of adjustments and improvements for future projects

After a project is completed, it must always be analyzed.

The purpose of project analysis is to determine the strengths and weaknesses of a project. It also assesses the economic efficiency of the project for the company and allows for making adjustments in current processes based on obtained data, thus improving results for future projects.

Stages of analysis:

Gathering all project participants’ feedback. For this, each participant must be sent a list of questions about the project’s pros and cons.

Requesting feedback from the client. These questions are nearly identical to those asked to project participants on our side. Customer feedback is very important to us since clients’ negative comments help us improve. Add all feedback to one Google Doc, and share it with the Director and Senior Manager, if applicable. Analyze feedback, make conclusions and make changes to work processes as needed.

Write a letter with these conclusions to all project participants, and copy the company Director and Lead Manager. An example of such a letter can be found in the links section.

Before starting the next project, discuss the previous project’s problems, if any, in a meeting, and state what has been done to eliminate them. If there were no problems, simply state what innovations emerged after analyzing the project.

This analysis must be carried out for all projects, even those the PM personally finds to have been successful and even for small projects between 20 and 40 hours. As experience shows, the PM may not even be aware of some small points that the developers notice due to the differences in what their roles expose them to. If nothing bad occurred during the project, next time we can do even better.

Input data:

• Working site
• The presence of tasks for functioning maintenance
• Bugs or problems on the website

Participants:

• Project Manager
• Client
• TeamLeads and developers of the project
• Tester

The result:

• Functioning website without bugs or problems
• Client’s budget is used as planned
• Developer’s workload is carried out as planned

Website support (tech support) is a set of services aimed at maintaining a site, updating it and improving it. Website support in our company can be provided both to internal clients, for which we have made a site from scratch, and to external clients, who come to us with ready-made websites.

There are two types of website support:

1. Technical
2. Informational

We provide our clients with any website support that includes:

Technical website audit

We detect technical shortcomings of the site; check the download speed of pages; check the accuracy of the site’s mobile layout and check for the presence of key modules and updates. We also eliminate obvious bugs and offer solutions to problems.

Website updates

A website can be finalized or adjusted based on the objectives at a given moment. For example, a redesign can be implemented, new pages can be added or new modules can be installed.

Support of site functionality

Examples of this type of support are: creating regular backups of websites and databases; correcting errors arising in the work process; and scanning for viruses and malicious scripts.

Interaction with the hosting provider

This support includes the transfer of the site to a different server, restoring the site from backups, domain transfer and selecting new hosting.

Technical support may be periodical (upon request) or on an ongoing basis.

If we provide technical support on request, we usually solve the site’s specific problems. If the client is interested in support on an ongoing basis, we determine the number of hours per month and a fixed price for these hours.

Informational support mainly involves working with website content (updating or adding texts, images, or videos), and it sometimes also involves help with SEO promotion.