LAB 5 – Lessons Learned
TABLE OF CONTENTS
1Introduction
2Risk Management and Mitigation
3Budget
4Schedule
5Prototyping...... 31
5RWP Solution and Scope...... 31
1Introduction
During my time working on this project, I have learned many lessons that will prove to be valuable in future employment. I will seek to summarize these lessons in the text that follows, to document the changes that would be useful for subsequent projects. Each lesson is broken down to outline some of the key components of the project, and while mostly inclusive, this list is not exhaustive of all lessons learned.
2Risk Management and Mitigation
In CS410, our team drafted a Risk Mitigation Plan, which outlines some of the major risks our product may face during development and implementation. They were categorized in the following manner:
- Scheduling Risks
- Information Delay
- Equipment Delay
- Financial Risks
- Unforeseen Expenses
- Contract Penalties
- Technical Risks
- Technology Availability
- Marketing Risks
- Customer Diversification
Each of these risks was researched further and addressed with specific mitigation action items. For the list specified, I will detail whether or not the risk was successfully mitigated as well as the probability or impact change as a result of the prototype.
- Scheduling Risks
- Information Delay–This risk is dependent on how long the client will take to decide where they would like to place our sensors, and will not have any bearing on the success of our project. This did not change as a result of the prototype, as it is client-dependent.
- Equipment Delay – This risk is dependent upon third-party manufacturers who would be mass producing our prototype and creating the road signs. This did not change as a result of the prototype, as it is manufacturer-dependent.
- Financial Risks
- Unforeseen Expenses – This risk was mitigated to a large degree by proper planning, but there were still last-minute items to be bought during the prototype phase, that the planning team failed to identify. The way to cut down on this risk would be to add extra funds to the budget in order to cover small unexpected expenses. The prototype construction allowed us to see this need clearly.
- Contract Penalties – This risk is in regards to equipment delay that could cause a late delivery for the project. This risk is still possible but would be dependent on third party manufacturers, and did not have any bearing on our prototype development.
- Technical Risks
- Technology Availability - Despite research efforts, the information on the city of Norfolk’s networking capabilities is not readily available. This risk will be addressed by meeting with the client and determining what type of network they would like to tie into, wired or wireless. Upon that decision, we will outsource to an independent firm that specializes in large network implementation. For that reason, this risk is mitigated and did not have bearing on our prototype.
- Marketing Risks
- Customer Diversification – Initially, we only identified one customer to whom we could market our product. Upon further research, we were able to expand our target market to include several others, thus mitigating this risk. Our prototype development did not have any bearing on this risk.
2Budget
Our team budget was handled privately, as opposed to the rest of the course participants. We decided to fund our prototype independently in order to obtain the ownership rights to the components for future use. If we were to use the budget that was made available to us, we would not have had enough funds to build our prototype as we did. We estimate that our prototype cost us $230, whichis $130 over the budget provided. While it does vary by project, it would be helpful to increase the budget for future projects, or to decrease the amount that is expected to be demonstrated with components other than a development machine. In regards to the Phase 2 budget prepared in CS410, we were right on target as far as estimated cost. Therefore, given proper planning, no changes should be made to Phase 2 budgeting.
3Schedule
In developing our prototype, we did not encounter any issues with regards to scheduling. We began our prototype planning and development in enough time to successfully build and test our product before we were required to demonstrate it. It did not nearly take us the four months given to develop our prototype, but this was desired, as it gave us time to develop more features to add to the final solution. At certain points during development, the timing was very close to meet specific deliverable deadlines, but as the project manager, I directed the team to meet outside of the classroom as needed, in order to meet the required target date. No changes to Phase 2 scheduling are needed in my opinion.
4Prototyping
While developing our prototype, I found both positive and negative aspects to managing the team. On the positive side, I am grateful to have had skilled team members who went above and beyond to help develop the product. They often worked outside of the classroom, taking initiative to complete tasks undirected, and covered costs out of pocket. It is because of these colleagues that our product succeeded. I gained two new team members this semester, and due to the large number of people, I organized them into two task forces: hardware and software. This way, the more learned students could teach the beginners and cross-train which I feel is important. While broken into teams, this also created a more positive, fun, collaborative environment and production increased. On the negative side, I was unable to assign the same level of tasks to each team member due to skill level. There are some team members who simply knew more than the others and they took on the majority of the work, while others were placed on research related tasks. This was not preferable; however this is why I created the two task forces to cross-train, so they did not feel as if they were wasting their time. Also, if a team member did not contribute as much to the prototype development, I had them take on a more active role in Lab writing or presenting. Another problem is that of reliability in regards to deadlines. Some members of the team did not submit their materials by the due date, which held up other members of the team who were relying on their submission. This would be handled in a real-world environment by corrective action. The last problem is that of work quality in regards to team member submission. I often found that what the team members turned in as a result of an assignment was not adequate to submit for grading. In this case, I personally tweaked or completely changed parts of the project which some members became offended by. They would have preferred that I turn in their work untouched even though it probably would have earned a lesser grade. I personally oppose this view, as I feel that the project should not suffer in quality on account of appeasing the parties involved.
5RWP Solution and Scope
In my professional evaluation, the SWD real world product design will need to change from what we have documented, because it is largely based on the client’s wishes. Our plans would differ drastically if the client chose to have a wired network vs. a wireless network for example. Also, the technical details surrounding the Onsite Data Acquisition Device (ODAD) will change considerably given the client’s preference between physically plugging in the device or simply driving by, using RFID to obtain the data. The last point to note, is that the RWP will be utilizing industrial strength parts, while our prototype is not. This is the last major area I foresee the project changing.
1