# Project Management Intermediate Report
###### tags: `Review` `Deliverable` `Ideation`

### Supervisor feedback

Our vision description seems very focused on the client side. That means that when we describe our product, we give too much relevance to the Talkdesk perspective, and too little to the company perspective. We should try and change this around.
Moreover, he also referred to a "mitigation plan", and if we had already discussed that with Talkdesk

#### Project description and client
The project was suggested by Talkdesk.
Talkdesk is a company that offers call center-like solutions for companies.
Talkdesk currently has a marketplace with apps that complement the main product. These apps can be submitted by external developers, but the process is currently not very efficient, involving google forms for submissions, email exchanges between the developers and the Talkdesk team and full manual verification of every app submitted by the Talkdesk team.
Wishing to improve the process, Talkdesk asked for a product that solves that issue, a platform that offers the external developers with a better experience for submitting their apps and that lightens the burden for Talkdesk workers by making automatic checks to the submitted product. This platform should make it intuitive for the developer who checks the state of the products submitted by him/her. On Talkdesk’s side, this platform should have an easy way to access all submitted apps and an intuitive way to access each app’s contents to analyze and to decide whether the app is allowed to enter their marketplace.

#### Team and organisation
Our team is led by Pedro Lopes and is composed of 11 people:
* Amr Abd Alrahman \[MIEIC] (Back-End, Tests)
* Christopher Abreu \[MIEIC] (Design Management)
* Diogo Teixeira \[MIEIC] (Implementation Manager, Full-Stack)
* Filipa Durão \[MIEIC] (Costumer Interface Management, Responsible for Documentation, Front-End)
* João Alves \[MIEIC] (Design Management, Back-End, DevOps)
* Luís Oliveira \[MIEIC] (Front-End, FullStack, Documentation)
* Olavo Silva \[MIEIC] (Implementation Manager, Back-End)
* Pedro Lopes \[MIEIC] (Costumer Interface Management, Back-End, DevOps)
* Ricardo Silva \[MIEIC] (Back-End, Tests)
* Joana Camacho \[MESG] (Services)
* Maria Leite \[MM] (Multimedia)

The team is divided into 6 major departments, each of which has a redundancy in its management (the redundancy allows for at least 2 people to be aware of everything in said department, so if one person is absent the other can fill in):
* Costumer Interface Management - Pedro, Filipa
* Implementation Manager - Diogo, Olavo
* Design Management - Christopher, Joao
* Test Manager - Amr, Ricardo
* DevOps - Pedro, Joao
* Docs - Filipa, Luís

#### Communication and coordination mechanisms
* Slack is used for daily communication as well as important announcments.
* Each week the team has a dedicated meeting to discuss what has been done and what should be done next.
* After each meeting with the supervisor or the clients, the team does a small meeting to discuss what has been said, as well as create action plans.
* Every week the team leader places on Slack what tasks have to be done for the next week.
* Each team member chooses a task that he/she can best serve at.
* Team members revise each others work when it finishes and provide feedback.
* Each meeting is well documented by the teamleader, which enables absent members to catch up quickly to what was discussed.
* There is a dedicated channel in Slack for consulting with our supervisor. Any problem that the team has and the team agrees that it should be elevated to our supervisor and cannot be solved internally, gets elevated up to that channel by the teamleader.
* Any question that a team member has is discussed on Slack and only recorded by the team leader if no solution was found. The question is asked by the team leader on the next meeting with supervisor or clients.
* The team leader requests for a meeting with the clients when the team has many questions and the meeting could be fruitful.
* Team members have an agreement that the team leader is the one responsible for managing meetings and asking pre-defined questions during the meeting. However, any further questions that occur to any team member during the meeting can be expressed by that team member. This has helped in shortening the meetings time considerably.

#### Project management practices and activities
We'll develop our project according to the Scrum framework. Scrum is a lightweight process framework for agile development, a group of software development methodologies based on iterative development.
For that matter, we'll have the following activities:
* Sprint of two weeks with a sprint planning at the beginning of each one, to establish what is going to be developed in that sprint. Resources and work allocation will be determined for each sprint and issue.
* At the end of each sprint we'll do a Sprint Review and a Sprint Retrospective to inspect the increment developed and the team itself and improve from that acessment.
* We'll also hold meetings twice a week for the whole team to know what each member has done, is doing and will do as well as adress everything that needs to be dealt with.

Some practices have also been established in regard to coding and work integration standards and best practices.

#### Schedule progress against plan (Is the project ahead of or behind schedule?)

All deliveries are being made on time except for the project prototype, which was late due to an overflow of sudden work on the Multimedia team. This has been taken care of and will not affect the final outcome of the project neither will affect the scheduled plan.

#### Current scope compared to plan (Has the scope changed since the project began? If so, how?)
Instead of thinking of a product specifically for Talkdesk we are now thinking of a more broader solution so we can meet the needs of more potential clients.
We started the project with Talkdesk's idea in mind. However during the ideation phase we realised we could adapt the submission form and adapt to other companies' needs as well as the workflow process since it's basically just putting in and taking out components.
This solution can easily be adapted to other submission platforms as applications to human resources, call for papers, contest submissions, social media profiles, and so on.

#### Planned versus actual resourcing (Are any resources missing or over allocated? Weekly progress)

Every resource is currently well allocated, every team member has a set of target capabilities and tasks are distributed acordingly.

#### An overview of risks (Are there any high risks that need to be managed?)
* There are still a few technologies we need to study, and as such, technological difficulties may be encountered during the development.
* In the current state of affairs due to the COVID-19 pandemic there is the possibility of any member becoming infected, despite the mandatory isolation. However, with the contingency plan prepared by our company and with the redudency we've planned for every role in our team, those risks are, hopefully, minimized and properly addressed.

#### Current quality findings (Has quality testing been done? Were there any issues?)

No quality testing has been done yet, since the development is yet to start.

#### Lessons learned (Strengths, weakness and what has been improved)

***Strengths:***
* All team members are committed to deliver work on time.
* All team members are willing to help each other when needed.
* Work is well-divided between team members.

***weaknesses at the start of project:***
* Lack of communication.
* Meetings used to be unorganized.

***Improvements:***
* Communication between team members has improved drastically over time.
* Team meetings are being managed better than the start of the project and are being more effective.

#### Project plan for the build-measure-learn phase (High level plan but with a clear indication of planned releases)

The team will organize the work into **2 week long Sprints**.

The **Sprint 0** will be be the sprint to make all the necessary setups to start the development.
The **Sprint 1** will be the sprint to work on the submission workflow creation with manual and automatic checkpoints.
The **Sprint 2** will be the sprint to work on the Workflow Monitoring.
The **Sprint 3** will be the sprint to work on the Submission and Self-sustainability documentation.