RIT will permanently shut down the RIT Wiki (Confluence wiki) on February 2, 2024. Review the Wiki Shut Down Overview for information on alternative tools, exporting content from the wiki, and other FAQs.
...
Current state of the project
The finished assembled device was able to meet most of the customer requirements and meet the design goals that the team set out to meet during MSD I. The team was able to produce a functional prototype that is able to lift and lower a user, and is stable. The device features arms rest that are free to rotate and overall the different aspects of the device function as it was designed too. The requirements that are unmet are the weight capacity requirements. The team was unable to get the hydraulics to go up and down in unison when in a parallel configuration, so the team switched to series. However, this reduced the lifting weight capacity to only 90 lbs. If more time was given, larger hydraulics could be used to fix this issue and increase the weight capacity of the device. The final device is robust and functions as designed. The team was also underbudget for the project, about $100 under. Our customer Art North, I believe was satisfied and happy with the final device we produced. He seemed to like the arm design and was happy with how the device lifted and lowered. The completed customer requirements and performance vs requirements table that was added to the engineering requirements can be found here.
- Compare your current project plan/schedule to your original plan/schedule.
- Did the scope of your project change during MSD II?
- How and why did your schedule change during MSD II?
- What have you learned from these changes that you can apply to future projects?
...
The team managed to closely follow the semester plan for MSD II. The team was able to meet deadline for the technical paper, imagine RIT video, and draft poster, since we all started a head of time and were finished by the date the team established as the deadline. They were also all turned into MyCourses by the due date. The only scheduling changes that majorly effective the team was that the system level build and test design review was pushed back due to scheduling conflicts, however, this allowed the team to have more time to get aspects of the device completed and tested like the arms. Since the team has been ahead for most of this semester, compared to other MSD team, the team also created ample space in the schedule to complete task since, we had a big head start in the process. From the scheduling of MSD II, I learned that it is better to be productive at the start of your project (or in MSD I) since if you do the hard stuff in the beginning, you will have plenty of time to troubleshoot toward the end of the project. This eliminates stress, and you can be more satisfied at the end of your project, knowing that you did all you could, and do not regret that you did not have time to accomplish something.
Review individual team member status:
Hannah- I felt that I delivered on all my personal responsibilities. I was in charge of making sure the team meet all our official deadlines, planning when the customer design reviews are held, as well a what the team is going to work on every team meeting. I believed I helped the team stay on track and helped to get the team going and focused on the project. I believe I used the MSD II plan effectively. The schedule help me figure out the team goals for each phase, and what our focus/tasks should be for each meeting. I could then effectively assign other task to members, and make sure we are working effectively. I believe the plan was realistic, since I originally counted on some delays, so the team was able to get ahead, and when errors or problems came up, the team was not set back at all.
- Did you deliver on your personal responsibilities?
- Did you use your MSD II plan effectively? Was it realistic? If not already addressed above, what did you learn from this and how can you apply it to future projects?
...
Current Risk Assessment and Problem Solving Status:
At the end of the semester, all the remaining risks were closed out for the team. Since the team has produced a working prototype by the end of the semester, the risks regarding not meeting deadlines or not creating a working prototype were closed out. The risks that we did not anticipated included those surrounding the hydraulics not working initially. This was because when we received the hydraulics, the other team had stated on their edge page that the hydraulics were operational, but we quickly found out it wasn't the case, and we have spent a good part of the year getting them to be functional again. A few of the risks became problems, like regarding the hydraulic mounts, the O-rings inside the hydraulics, and the hydraulic pistons. However, the team was able to implement a solution to all these problems, which were reflected in our problem solving document. The problem solving process, we used this semester was that we identified a problem, then as a team we began to brainstorm different solutions that we could try. The team then selected one to implement and then we retested the device or system to see if the change was effective. This method worked for the team, and the team was able to at least implement one solution for every problem that come up over the course of the year. The updated risk and problem tracking documents are found below.
Deliverables Checklist and Website Status
The customer handoff has been completed. All tools have been returned to the MSD office and the locker has been cleaned out since a another continuation project is not believed to be happening at this time.
Lessons learned, etc.
The team learned that the best way to see if a designed solution worked was to test it out and to grab whatever materials are were around to test it out. That was how our team came up with a lot of our solutionsolutions, which were occurred when the team just to "send it". This just going for it method, allowed us to fix the bearing guide spacing issue as well as the hydraulics not going up in unison issue.
The advice I would give to future team, is to do not send spend all your team time planning out a perfect design, since it most likely will not work the first time so start building as soon as possible to maximize your troubleshooting time.
...