Last Thursday (March 5th) we finished our first ‘real’ sprint. It was the day we had the sprint review with our assigner, the Port of Amsterdam. During that review, we presented our findings and ideas, just like we’ve done the day before during the peer pitch. This blog post will explain our insights using graphics created by Sanjay (Click the images for a bigger version).
At first it was not entirely clear what our assignment truly encompasses. Therefore, we chose to go with an analyst for a couple of hours. During those hours we really found out what the analysts are responsible for. It is clear that there is a lot more to it than just checking the work of the contractors. We were asked to get rid of some subjective elements in the work of the analysts. We actually found out that the subjectivity is quite important. The subjectivity ensures that the relation between the contractors and the Port of Amsterdam is a good one. It is this relationship that contributes to the clean port. We also discovered that experience is key to the work of the analysts. Navigating to and from specific points, for example, is really dependent on the knowledge of the analyst: how well does the analyst know the area? In the image below you can see that there are two assessments: the daily and the monthly. The daily assessments are meant for keeping the port safe and clean. A misplaced traffic sign will affect the safety of the port. It is therefore important to report these errors. The monthly checks are meant for reassuring that the contractors will not slack in their work. This also ensures that the port stays clean at a constant level. At this time there are three analysts as you can see in the image below. It is important to note that not all analysts do daily assessments, only one analyst is responsible.
The assessments
Workflows
During the time we went with the analyst we also noticed the workflow of a couple of processes. The first of these processes is the navigation. During the monthly checks, the analyst has to check a couple of specific areas in the port. All those areas are on a list right now. Each area corresponds to a specific number. It is up to the analyst to find the specific area corresponding to the number. Once the analyst finds his goal on the map, he has to drive to that specific area, which is a 100m2 square. You can imagine that it is quite hard to determine if you are in that square. The analyst has an app to check if he is in the 100m2 square. Once the analyst is done with checking the area, he repeats this process. You can see the process in the visual below.
Navigation workflow
The analyst has to check each area on the list. For this he has a separate iPad app. The first thing to do is to determine the specific category. After that, the analyst has to check every possible aspect on the checklist presented on the iPad. It occurs often that certain items are inapplicable. It is pretty common that there are no benches in the area, but the checklist will present the bench-related items either way. It is also in this process that the analyst’s subjectivity comes into play. The area may look really dirty, but the analyst knows there are some things to take into account. The weather has effects on the cleanliness of the environment for example. Some places are impossible to clean completely. Sometimes the area is dirty because of a construction site nearby. Rather than blame the contractor, the analyst thinks about the problem more broadly. It is this personal understanding with the contractor that is really important in the process of keeping the port clean. The image below illustrates the workflow of this process.
Grading workflow
The daily assessments are a bit different. There is no specific area nor specific time when these assessments take place. This is perhaps best illustrated with an example: The analyst is on the way to a meeting. On the way to that meeting the analyst sees something that is off. The analyst has to get out of the car to report it to the contractor by taking a picture. After that the analyst continues his journey to the meeting. The daily checks take place all day, whenever the analyst is outside.
All in all the processes are quite complex. Therefore we decided to visualize them like loops in this illustration
Insights
Based on these workflows we got some insights and ideas. The first thing is to keep the subjectivity in play. The subjectivity is a really important part of the job. The second one is that the navigation part can be optimized. The process is a bit of a hassle right now. We have come up with an idea to solve this problem. We also want to tackle the daily object spotting with computer vision.
Navigation and workflow
To make navigation easier for the analyst we decided to get rid of the paper list with all the areas that have to be checked by the analyst. We want to make some kind of planning system that generates the most suitable route to those areas. We want smart eyewear to give the analyst subtle direction to the specific areas. When the analyst is near or on the right spot, the eyewear will give him feedback like: “Hey, you’re 5 meters away” or “You’re on the right spot”. This way we hope that the analyst doesn’t struggle with the list and the iPad. We will try to explore this idea another sprint.
Navigation idea
Object spotting
This sprint we will focus on object spotting. We specifically want to spot traffic signs for now. When the analyst is driving, it is easier and safer to keep driving. Now the analyst has to stop and get out of the car. This can result in dangerous situations. Therefore we want to automate the object spotting. With a car-mounted camera we can look for traffic signs with computer vision. We already built a prototype that can recognize shapes (previous blog post). We can use that prototype to go even further and build a TSR (traffic sign recognition) system that automatically detects signs that are off. This will make up most of the current (second) sprint.
Automated object spotting
Other insights
There have been some other insights. We know now, for example, that Glass is quite hard to work with. The hardware of Glass is limited, heavy processing should be done externally. This leads to another insight on Glass: communicating between Glass and an external device is not straightforward. This means that all kinds of different workarounds must be implemented. Another insight is that we need to consider other users of the product. For now we focused on only one user, but there might be multiple users that are affected by our solutions in some way. We also need to document more. While we documented everything in our Google Drive, we still lack visual documentation that should accompany these texts. But hey, nothing is perfect!