This week, we finished up our PDR Report and Presentation. We spent plenty of time practicing our presentation to make sure we were well prepared and ready to present. On Friday, we presented our PDR to our sponsor, liaison, and other American Express guests. Our presentation went very well, and we learned a lot from answering questions from and talking with the other guests from American Express. We’d like to thank everyone involved for their valuable feedback and insights.
Our next steps are to send our PDR Report to our sponsor for final review and signatures, and to start purchasing the hardware that we need to complete the project.
This week, our team presented our PDR Presentation to the class for peer review and finished the first draft of our PDR Report. In class, we presented our initial PDR Presentation and received feedback from our classmates, which we will be using to prepare for our meeting with American Express next week. In our meeting with our liaison and sponsor this week, we showed them our presentation and got feedback on it. Based on their feedback, we will be making changes to our slides to fix the issues they brought up.
Over the next week, we plan to make fixes to our PDR Presentation and Report in response to the feedback we received on both. Also, we plan to finish the UI/UX mockups that our sponsor requested. Now that we have a better idea about the final scope of the project, we can start ordering the items we need, such as Raspberry Pies and Bluetooth beacons.
This week, we met up on Sunday to get some of the details of the project ironed out. We worked on our both our Software and Hardware Architecture Diagram, to make sure we had everything sorted out. We decided on using a Raspberry Pi for our initial proof-of-concept prototype hardware to ease the development process. We also decided on specific Ultra WideBand (UWB) hardware that we would use to pinpoint the location of the customer’s car.
In our meeting with our sponsor on Tuesday, however, the scope of our project changed. After talking with our sponsor and liaison, we decided on not having any custom hardware in the customer’s vehicle. Instead, all of the communication/processing would happen through the customer’s phone. In addition, our sponsor wanted us to develop a system where the customer could place their order directly through their phone, using AMEX’s closed-loop payment system. With this change in scope, we have a lot of work to do.
This week, we finished and submitted our project roadmap for the first semester and our First Month Report. We selected concepts for both our hardware and software this week as well, after discussing them with our sponsor. On the hardware side of things, we’ll be using UWB (Ultra Wide Band) to allow the merchant’s device to locate the correct vehicle. Then, the in-vehicle device and the merchant’s device will connect and transfer transaction information using Bluetooth. Our current plan is to use a Raspberry Pi for these devices, as it is a simple and inexpensive development platform. On the software side of things, our team has decided on using React Native for the mobile app framework. React Native is widely used and well-documented, and has support for many communication standards such as Bluetooth.
For next week, we plan on starting on wireframe prototypes for both the customer’s mobile application and the merchant’s device UI. Also, we plan on creating a new physical high-level architecture and component diagrams to describe interactions within the system between the user, in-car device, and merchant device.
Our team finally met our sponsor this week! In our first meeting, we compared our thoughts about the project and ideas for solutions. We discovered that our sponsor’s requirement for the system be “hands-free” was less strict than we had first thought. With all that we learned from our sponsor meeting, we needed to update our specifications and requirements as well. We met up several times during the week to do this. After our meeting with our sponsor, we redid some of our storyboards to make sure we were all on the same page.
Also this week, we started our roadmap with the deadlines for our most important deliverables. This will be worked on and updated throughout our project. We also started on our risk assessment with potential points of failure that could require changes to our roadmap.
Over the next week, we plan to narrow down and decide on the concepts for parts of our project, such as communication technology and software framework.
In class this week, we presented our logo and team name. Our team name was well-received, but there was some constructive criticism about our logo design. We simplified the overall design, and made some changes to address points that our classmates brought up. We also worked on our Product Development Specifications document, which includes our specifications, customer needs, and features. The requirements and specifications were ranked in order of their importance so that we know what to focus. This was done by using a “house of quality”, a table in which the specifications are ranked by rating their relationships to the customer’s needs. We have scheduled regular meetings with our liaison, in which we will discuss these specifications and requirements.
Our team also started brainstorming concepts for solutions to the major problems for our project. We plan to meet again before the next class meeting to discuss and improve on the concepts that we are coming up with individually. We will also research and review various potential communications technologies that may be used in our project.
Our first order of business this week was creating a proper logo. Our previous one was created in a minute or two on an iPad. We had a meeting where we all gave our input and created a new logo design, which looks much better than our previous one.
We also set up a progress tracker within Teams to help us organize our work and deadlines. In our team meeting on Wednesday, we discussed our PDS and worked on it together. Then, we worked on our idealized storyboard. All of our ideas for how the product should work were fairly similar, which made this easy. Some sort of device inside the customer’s car would communicate with the payment terminal. The transaction would be shown on a display inside the vehicle, and the customer could confirm this transaction hands-free with a voice command. The merchant could see and confirm the transaction on a cash register. Ideally, this would integrate into existing merchant-side devices.
We are Team 01, also known as “Easy Money”. I’m Andrew Watson, the current Blog Editor for Easy Money. Together with the rest of my team, we are excited to be working with American Express to develop DrivePay™, a system with the goal of transforming a motor vehicle into a payment device. Our objective is to develop a system that allows a customer to initiate a transaction just by driving next to a DrivePay™ enabled merchant, and complete said transaction completely hands-free.
So far, we’ve just been doing some initial planning and organization of the team. We’ve also started brainstorming possible ideas and solutions, which we’re excited to discuss with our liaison. We all have high hopes for this experience, and look forward to working on this interesting project with American Express.