The first capstone project I was assigned to suffered from scope creep, or rather a lack of scope definition. When the professor was describing the project at first, it was rather vague and only described the subject that the project would be about; in this case, it was based around the 3D imaging software MIMICS. After our group had decided to work on this project, the professor then decided to tell us more details. Purportedly, we were to program an add-on to this software that would expand the capabilities of the software. With us being undergraduate BME students with very little computer science experience however, it became apparent to us after numerous meetings with another adviser that this project would fail. At the end we simply had to part ways a third into the semester and rush to find another capstone project to join into.
This year my capstone project suffered from scope creep because we did not have a defined end product. We essentially would complete the main project task, and if we had time then we would start discussing other tasks that could be done. However since our expectations were mainly for the one project, we did not plan in any time to attempt the action items out of the scope of our project. However if we had planned them in from the start, we would have been able to get farther in the overall project.
Recently, there was a project I was on that had two instruments removed from scope earlier on in the project as this project was worked on by different divisions of the company. The two instruments were removed from scope for my team, but had managed to be moved from division to division until it had come back onto our scope list without much work being done in the interim between exiting and entering the project team again. This unfortunately needed attention before the project could move forward as it was right before the team finalized the scope and was ready to move onto the next phase of the design process. I personally didn't have any effects from the added scope, but the R&D engineer responsible had luckily kept tabs on the two items in the trace matrix that could easily be re-added without too much headaches. The only tasks that myself and the team needed to be diligent for were the design reviews that would essentially catch the two items back up to the current review needed for the project to keep moving forward. Although I personally didn't resolve this, I would definitely say its a good lesson from the senior engineer on the team to remain vigilant on items that may reappear that were removed initially. He also, from his own experiences, knows which pathway the project needs to go through to add any items that were introduced again, or (from a different project) to stop the addition of items that could have been added due to scope creep through rationales.
My capstone project for undergrad focused on creating a continuous passive motion device (CPM) for the hand. We underestimated a lot of the completion dates for many parts of the project which resulted in a lot of scope creep for the project overall. We ordered parts late, started 3D printing our design late, and spent a lot more time thinking about building instead of actually building and then testing our device.
We had about six months to design, make, modify, and create this device but ultimately ended up finishing our single prototype just as the deadline was approaching. The mechanical part of the device worked as intended and could open and close a hand, but the mechanism used to control it was a disaster. We had originally wanted to use force sensors to change the direction of a motor but no one in my team had enough experience with software and hardware to make anything that could do such. since many parts of the design were designed around this system, we had to change many sections last minute to accommodate for the control system that we were able to make.
Had we planned better or set our plans more realistically we most likely would have had a better, less hackneyed device.
I experienced scope creep throughout my capstone project. The scope creep was encountered in the project description portion of the scope determination. Due to the relatively short time period of the capstone project, the product description was determined before material research and testing was complete. For this reason, the product description was fairly vague to show the general requirements of the product, but as more information on available materials and physical properties of the materials became available the initial scope determined was not entirely accurate and had to be adjusted based on the new information.
In my Senior capstone project, we had multiple initial design choices that we had to pick from based on our very limited understanding of the project. However, as we kept developing the project, we realized that our scope had changed and made it so we has to adjust our designs to match this new scope. These design changes we luckily caught very early on in the development of product. But it lead to changes in our design documents and Gantt chart. If this was a company project a better understanding of the project scope would have most likely already been part of the project rather than being quickly adjusted along the way.
Like many others, my most prominent experience with scope creep was through my senior capstone project. The project that my team thought of was to create an assistive communication device for patients with motion and speech impediments. Through a combination of both new findings and our customer (our advisor) requesting adjustments, the project we had initially began with had changed quite a bit. Ranging from the design of the assistive communication device to the exact electrical mechanisms for how the device would work, many aspects of the initial project had been adjusted over time. This caused for many of the documents created for the project to also be adjusted on multiple occasions. In terms of the customer requesting changes, there was not much that could have been done to prevent this from happening. I believe this would apply to industry as well. However, in terms of the adjustments made by the team based on new findings, I believe that with a better planning and research phase, this could have been avoided. This would be different within industry compared to our senior capstone project, since there would be much more research conducted before the project begins within industry.
While working as a research assistant at a lab on campus, I experienced scope creep while developing a custom motion capture system for a gait analysis. The project involved the use of inertial measurement unit sensors to record the real-time angles of an individual’s lower extremity while walking with a robotic exoskeleton. The change that was initiated was to use a different microcontroller to increase the sampling rate of the data being recorded. Due to this sudden change, we encountered challenges when we realized that some of the electrical components and software libraries implemented in the original design were not compatible with this microcontroller. As a result, we had to switch back to using the original microcontroller that was planned for this project. While we were able to complete our project on schedule, we also learned some valuable lessons regarding scope management. The major lesson learned was that the team should have spent a greater time during the planning phase defining technical details such as the desired sampling rate. This would have allowed us to select the use of electrical components that were compatible with each other and met our desired project objectives.
In the field of research, I feel as though scope creep happens more often than a project stays on track. In the current lab I am working in, projects change rapidly as the results of experiments come back. Many times, I am asked to complete side projects for my PI or different members of the lab need help with different projects. Other times results from my own experiments come back and instead of staying the course of what I originally aimed to determine, I find myself walking down a path to an entirely different question. In this situation, the most essential response on my part is to have my goals or aims easily accessible. Before planning any experiment, I ensure that the experiment I will be performing is going to try and answer a specific question that is relevant to me. Usually, I catch myself or another lab member who will point this out to me before I go too far off course, but something I can do better is standing my ground when people ask me for different favors that would delay me. Some of these principles come into play when deadlines approach, although on a smaller scale than a medical device project, for different grant submissions and exams. This class overall helped me learn different tools that apply now, and upon graduation, I can review and be ready to enter the workforce.
This is a slightly different view point than the other discussions in this thread.
At my previous job as a test engineer, one of the things that we had to do was write protocols. Since I had never written a technical, straightforward piece before, I was very unsure of how to approach it. At the beginning of each protocol, we had a section for the scope of the project. The hardest part for me was trying to be as specific as possible about what the project consisted of, yet still being succinct and sharing the necessary details. Initially, the "Scope" sections that I were writing were lengthy simply because I was overthinking what needed to be included in this section. However, over time, I was able to easily address this section and just point out the relevant things that needed to be mentioned and any references to historical information. As the project grew and change, we would redact the document and revise it to account for these new additions and then submit the revised protocol for approval. The biggest thing I learned during all of this was focusing on the bigger picture of the project and what it hoped to accomplish, rather than each minute detail that went to making up the project.
My team definitely experienced scope creep during our Capstone project. We were originally interested in working on a certain project, but after meeting with our potential advisor and going over all of our BME backgrounds, a new and exciting project was offered to us. We accepted this project and began our literature research. We had a general idea of the main requirements, but what we didn't expect was our advisor changing certain specifics. Our project was more of a novel laboratory instrument rather than a medical device, and the scientific literature on it was constantly being updated. We'd come up with a design and would want to move onto finalizing it, but then a new change would be introduced, material or design, and research would be needed to back up its viability in the project. Doing so took a lot of time. We were successful and still managed to complete the device on time, but there were moments where some tasks were such as ordering parts were pushed back. It created an intense time crunch at some moments that probably could have been avoided.
HAHA! Every day at my workplace. As I work at a small company, we are often at the whims of the CEO when it comes to new projects. Scopes can change depending on their desire or vision for the company's future. One particular project that had gotten a bit out of hand, but was reigned in, was a circular shaped device that needed plasma cut half moon plates of 3/8" thick steel. When the project began, all we had was a circle jig & a tiny plasma cutter. All that was needed was some time and patience to cut out all our pieces. However, our CEO wanted to have a more robust system in place for future jobs. So he ordered the largest mobile plasma cutter available. He asked us to do some research on plasma CNC machines that could be converted to run our new cutter. Until we noticed one of our vendors does CNC plasma cutting in house!
So, we chose to have the pieces cut out at our supplier. In the short term; this saved us tons of money and time. However, if these items become more popular, we'll need to invest in a more robust solution.
As many others, I’ve also experienced scope creep during my capstone project. For my capstone project, my team and I had to develop a software application in MATLAB to process fNIRS data. This required us to understand fNIRS data, the different ways of processing it, the existing software on the market, and what our product would entail that would make it competitive. It was a lot of work to do in a short amount of time, especially because my team members and I were not proficient in software development. Initially, we split the software into multiple parts, such as data trimming, denoising, quality filters, and user interface, and assigned each part to a team member. Each team member did literature research on their parts and got to writing the code for developing their part. When we got to writing the code, we all realized that it was essentially impossible to develop this software from scratch as it required understanding of complex math equations and complex programming on topics we were not familiar with. This required us to redo our whole project plan and scope, and change the deliverables to what we would be capable of completing within the capstone class timeline. We started meeting with PhD students from the lab weekly to gain better understanding of our modules and started looking at other software to analyze how they implemented different functions. Instead of focusing on each individual module, we started meeting multiple times a week to understand how everyone’s module worked and how each module would be connected to each other in the backend to ensure proper data flow. Although there were a lot of bumps on the road, consistent meeting and communication helped us complete the project by the end with a satisfactory product. To prevent this, better understanding of the project and technical skills would be required. The communication that came about team members during scope creep should have been there from the beginning. In addition, the team also should have appointed a leader that overlooked the progress of each individual, instead of it being left to each individual.
