I was solely given a records management project within a few months after I started working in my new Scientist role. Someone who had retired had started on it, but left the project of 20 boxes all disorganized. One of the worst things I hated about the project was that it was way above my head as I had no prior training in records management nor was I informed that I would be doing projects that I do not understand. Upper management did not know no more than I did about the records. An obstacle that I ran into is the basic knowledge that I did not have to do this task. I had to read trainings on records management and in person training. the project was due for completion by a certain time, yet I needed to train and complete the project.
An obstacle I've encountered while working on a project with a team is a delay in terms of a hardware piece not being able to be delivered to us in time for assembling our product. This particular product was on backorder and we assumed that at the least it would come in by close to the time of the deadline for us to add it into our final product and test it. However that specific part was so vital that it was the one part that could of differentiated our product from something else already on the market that we were trying to compare ours to. What we ended up having to do was omit that part of the scope of our project, and change the direction of our scope to solve a completely different issue. It was all last minute shuffling of plans and we ended up meeting up physically, about 4x that week so we didn't fall behind on the assembly of our project. To avoid this sort of issue in the future, and prevent it from happening again is to have a backup project idea that can utilize most of the same hardware parts, or at least not have the most interesting things about our product having to be relying on 1 singular part. Something else we can do is order the parts early on, and not depend on parts that are on backorder. We can double check how long they approximate the parts to arrive, and if anything will take longer than anticipated, we should cancel the order and come up with something else. Does anyone else usually try to have a backup project prematurely to them even working on their first solid plan?
An obstacle I've encountered while working on a project with a team is a delay in terms of a hardware piece not being able to be delivered to us in time for assembling our product. This particular product was on backorder and we assumed that at the least it would come in by close to the time of the deadline for us to add it into our final product and test it. However that specific part was so vital that it was the one part that could of differentiated our product from something else already on the market that we were trying to compare ours to. What we ended up having to do was omit that part of the scope of our project, and change the direction of our scope to solve a completely different issue. It was all last minute shuffling of plans and we ended up meeting up physically, about 4x that week so we didn't fall behind on the assembly of our project. To avoid this sort of issue in the future, and prevent it from happening again is to have a backup project idea that can utilize most of the same hardware parts, or at least not have the most interesting things about our product having to be relying on 1 singular part. Something else we can do is order the parts early on, and not depend on parts that are on backorder. We can double check how long they approximate the parts to arrive, and if anything will take longer than anticipated, we should cancel the order and come up with something else. Does anyone else usually try to have a backup project prematurely to them even working on their first solid plan?
A recent example of encountering an obstacle would be when I had to lead an experiment at work. It was a complex experiment that I had shadowed a similar version of previously, however I still found myself bombarded with issues on the day of due to unforeseen delays and inadequate preparation. I learned that although I had watched a similar execution of the study, I hadn't fully grasped the situation as so many moving parts were occurring at the same time that I did not have full visibility to. Although I tried to review the protocol in advance and find the answers to as many questions I had, I still found that unforeseen issues were still encountered whether that be in finding certain supplies or individuals trained in using certain equipment.
On the day of, a lot of problem solving was done by the members executing the study and many resources were tapped into to answer any questions we came upon. Although it was more time consuming, it helped us mitigate any mistakes we may have made along the way.
The planning phase of the life cycle could have definitely been worked on by gathering materials the day before to save time for trouble shooting of other issues. I also believe the closing of the previous project could have focused on logging any lessons learned that the previous experiment owner could pass on to me to ensure the study runs even more smoothly and benefits the team as a whole. The life cycle is obviously... cyclical, which is why I think it makes sense that the beginning and end of the project go hand in hand so well.
A project that immediately comes to mind is my capstone project. I was tasked with designing an aluminum mold that would create our desired shape of PDMS. The drill holes were about 1mm in diameter, so the slightest imperfections could skew our data. When looking at the cured PDMS with the naked eye, it seemed to be perfect, but under the microscope, there was a clear shift in the mold resulting in an imperfect circle. This error was determined near the completion of the project.
I believe a closer attention to detail in the executing process would have prevented this issue. It is believed that the mold shifted during the drilling process. Perhaps I was too comfortable after drilling several holes prior and accidently created this error. If there was more time allowed, we should have created a new mold. To overcome this obstacle in the interest of time, the team decided it was best to select the cured PDMS posts with the least amount of error. After running calculations, it was concluded that this imperfection did not negatively impact the expected results. The project finished earlier than expected, despite this obstacle.
Once obstacle that I will always remember because of the lesson I learned from it. While working on a project unexpected delays are part of the package, especially when you are working with a team. However because the manager I was working with was well experienced he had an contingency plan setup, just incase a delay of such calibre would occur. If they plan wasn't set up from the start, the team would not have been able to meet the deadline. Therefore it is always important to setup a contingency plan.
Recently, I encountered an obstacle at work that certainly could have been avoided if my team and I spent more time planning out the project. Our product requires to be sent out for sterilization as we do not do any of the sterilization on-site. This requires us to plan out and make batches ahead of time in order to give enough time for the product to be shipped to the facility and shipped back in time for commercial release. Although we had not foreseen such an issue, we had to suspend shipments for sterilization in order for the facility we use to implement and validate new sterilization protocols. Because of a lack of planning, we did not have enough batches to send out in the final shipments and as a solution, we had to rush the production of batches in order to make the last shipments. This definitely could’ve been avoided if we had spent more time in the planning phase and planned out batches in advance.
One of the most important factors that prevent a project from being finished ahead of time is additional work and the delay in the construction of the new project.
I will explain this by giving an example from my old job. Revisions of old works done while progressing in a new project are the biggest factor in the failure of the new project to progress. an emerging need for an overhaul requires a shift of the workflow there, and the progress of the new project is slowing down. This can be taken care of by employing more people, but this does not good for the employer. for this reason, you either prefer to close the gap by working overtime or you tolerate the delay of the job. In this case, the employee should contact a higher person according to the hierarchy and explain and inform the situation. If a top person in the hierarchy can solve this problem, he should solve it himself or he should transfer the situation to a superior person.
I met an obstacle while doing my final project in a physiology course. We needed to design an innovative product by ourselves. Since it required coming from our own idea, the shape and scale diameter must create by myself. I made a scatter and discussed it with my partner. We all thought that it wouldn't be a problem since both of us are known Solidworks at first. However, when we went to the drawing process, we found that we didn't notice the scale of our design was too small to add additional parts. We faced the problem of whether we should make a new design for these extra parts or not. Because the parts we want to add are necessary, we let this scope creep problem pass and re-draw a new design eventually. It truly took more time for this final project. Actually, we updated our project close to the deadline indeed. We solved this problem by cutting off the original design parts. We highlight the features that we think it's necessary to add. Make the basic parts simpler to save more time. I think our problem comes from our insufficient discussion and leaves no time for adjustment in our schedule. Therefore, setting up a detailed plan and leaving more time for project adjustment is important.
One of the biggest obstacles I have encountered in my work experience so far has been dealing with legal requirements when wanting to do a certain task. More specifically, having to understand the legality of consent when sending out information to different customers and the different standards to follow to make sure nothing is being done illegally with the information we have. The phase that should have been focused more on is addressing this issue in the early stages of the project. Everyone in the group looked over this aspect and it did not become an issue until we reached that part of the project. The previous phases of developing the information to be sent out all went according to plan and followed the timeline that we were given. Once we reached the legal barrier, that is when things started to slow down as we needed to get in touch with the legal department of the company, and sometimes it took days to get a response. Overcoming this obstacle took some time and a lot of research into the subject matter. There were a lot of laws that had to be reviewed as well as some terms and conditions to see exactly what we could do with the information we had. In the end, it was a valuable learning experience because it was a part of the business world that I had not really come into much contact with. While it was frustrating to deal with at the time, I can now look back at it and be happy that it happened because it gave me some valuable insights that I have taken with me to future projects.
One obstacle that I have dealt with on a previous project was lack of team cohesion. At the beginning of the Capstone process, I didn't put any time in planning out my team for the project. This lack of planning turned out to be a big mistake, almost costing me my grade. During the project, there were several instances where some of the members of my team were not showing up for important meeting with our professors and advisors. Eventually, this spiraled into these members not doing parts of the project assigned for them. I tried talking to my professors about the lack of commitment shown by those team members, but was handed a "too late" and "suck it up" response. Fortunately, me and another team member were able to complete the project, but we had several close calls. If I had to do it over again, I would've put more effort in constructing a team.
An obstacle that I encountered while working with on a project was when a project manager did not fully understand the strengths and weaknesses of the team that they built and established. This led to a delay in the completion of the project and rifts within the overall team dynamic. In addition to this, the goal began to change when it came to what was the true meaning of the project to each member of the group. In my opinion, the phase that we should have focused in most was the planning phase for the project and truly understanding the meaning of the project overall and developing a core group of team members who are able to complete the project and work as a team. When it came down o overcoming this obstacle, we ended up re-establishing "sub-groups" that could be used to provide guidance for each team member and gave room for each sub-group to focus on key points within the project. This became a positive step toward keeping the project afloat as well as completing the project overall.
An obstacle that I encountered an obstacle while working on a project that could have resulted in not reaching the deadline was actually in academia. I was in a group with three others, and it seems as though only one of the others were actually interested in completing the project by the deadline. The phase of the project life cycle I believe I should have focused on more was the planning portion. I believe if I would have stressed the importance of execution and set a deadline then it would’ve possibly been less stressful during the closing stage. Meanwhile, during the closing stage another peer and I had to take on more work from the others to be sure the project was done appropriately, thoroughly, and on time. The only way we recovered from the lapse was because we picked up the slack from the others and increased our workload. I learned my lesson for sure. For future reference, I feel as though roles, responsibilities, and expectations need to be put out in the planning stage so there is no confusion. How can you motivate someone who is on your team but they aren't interested in participating?
An encounter of obstacles that I faced while working on a project that could not have resulted in reaching the deadline was communication. While I was doing the science fair, my partner did not reach out to me and even left me out of a group chat. This resulted in me not knowing what was going on and being unable to do my part thoroughly. I had to meet at Starbucks to talk with her and ask her why she was doing that, and she said she thought I was too busy. I had to explain to her that I was not too busy and this was my grade too, and she tried to report me, so I got a different grade than my other counterparts. I later found out that it was because I got into a class she didn't, and she said it made her feel some way, which almost resultant me failing honors chemistry. After she put her pride aside, we made it to the state with our robotic arm. I was astonished because she was one of my closest friends. This demonstrated to me to avoid mixing personal with business relationships, and I took this with me throughout undergraduate and Graduate School. The problem started in the initiation phase, which was a big problem because it ruined the whole project since we didn't have a good initiation phase. It takes communication and being able to separate the two from each other to accomplish great things.
An obstacle that I’ve encountered while working on a project was not managing my time efficiently. I work in the R&D department, and I was presented with a project to test the repeatability and reliability (R&R) of a reagent. This project called for testing on 3 different instruments using 3 different lots, of non consecutive days, with testing 2 hours between the previous run. R&Rs are known to take some time because of the time restraints. This was my main obstacle, the time restraints. The first day I performed testing, it took me almost 10 hours to complete. This is very inefficient, and could potentially cause a delay in the project. I had to figure out how to manage my time more effectively and maneuver my system in a more efficient way. The second day of testing, I was finished in 7 hours, and by the 3rd day, I was finished in 6 hours. 6 hours is standard, meaning I was able to optimize my system to be more efficient. I did so by understanding how long each machine took to complete a run, also, by timing when each machine is finished with its reagents, because once it is finished with its reagents, it can be removed.
