CS411W
Lab 5 – Lessons Learned
Marissa Hornbrook
Surface Water Detection System
4/29/2011
LAB 5 – Lessons Learned
TABLE OF CONTENTS
1
Introduction ....................................................................Error! Bookmark not defined.
2
Risk Management and Mitigation ................................Error! Bookmark not defined.
3
Budget .............................................................................Error! Bookmark not defined.
4
Schedule ..........................................................................Error! Bookmark not defined.
5
Prototyping ................................................................................................................ 31
5
RWP Solution and Scope.......................................................................................... 31
2
LAB 5 – Lessons Learned
1
Introduction
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.
2
Risk 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
o Information Delay
o Equipment Delay

Financial Risks
o Unforeseen Expenses
o Contract Penalties

Technical Risks
o Technology Availability

Marketing Risks
o 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.
3
LAB 5 – Lessons Learned

Scheduling Risks
o 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.
o 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
o 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.
o 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
o Technology Availability - Despite research efforts, the information on the
city of Norfolk’s networking capabilities is not readily available. This risk
4
LAB 5 – Lessons Learned
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
o 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.
2
Budget
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, which is $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.
3
Schedule
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
5
LAB 5 – Lessons Learned
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.
4
Prototyping
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
6
LAB 5 – Lessons Learned
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.
5
RWP 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.
7