System Development Proposal
SIGMA PHI EPSILON
RECRUITMENT SYSTEM
SCOTT BLOCK
DAE KIM
AARON SCHACHT
NAVEED SIDDIQUI
Executive Summary
Sigma Phi Epsilon (SigEp) is a fraternity founded in 1901, and the chapter at the
University of Maryland was most recently re-established in 2003. It has grown its
membership over the years, currently standing at 98 members, making it the largest
fraternity at Maryland. As such, the organization attracts hundreds of potential new
members every semester for its recruitment week.
The current system of monitoring recruits is a Google spreadsheet that is available
for read/write access to the recruitment committee, which is composed of nine fraternity
members. Recruits are categorized in different colors: green for target recruits, blue for
recruits approved for membership, and red for recruits who have signed.
In unstructured interviews with the vice president of recruitment, our team
identified areas for improvement in accountability of committee members. We were told
that in many cases if a committee member commits to a particular recruit as his target
recruit, there is not a clear way to note that and keep the committee member accountable.
Our objective with SigEp was to create a transparent recruiting system that can
get both members and potential members more actively engaged in the recruiting process.
The new system would be web-based, so it would be more accessible to potential recruits
and active members. Instead of initial registration being limited to recruitment events and
on paper, it could be done at an applicant’s convenience online. This would eliminate the
need for a committee member to upload the applicant information to the Google
spreadsheet, as is the case with the current system.
To address the accountability issue, the new system would allow committee
members or the vice president to clearly assign target recruits to a specific committee
member.
Our team looked into external solutions for the new system, and while there are
companies that offer solutions for communications, financial and Greek website systems,
a recruitment system that our team was looking to implement is not readily available.
That is why we decided on a custom solution, as is reflected in our candidate systems
matrix.
Ultimately, our team and the client decided that the custom solution made using
Visual Studio was the best option for both parties. The project team all has experience
with Visual Studio, and we feel that it offers a simple, user-friendly interface that will be
easy to manage after implementation.
Implementing the new system by the spring 2014 recruiting season was a goal
identified by our team, and we fully expect to accomplish it. Since specific or private
information about applicants is not carried over from semester to semester, the technical
transition from the old system to the new system should be smooth. We plan on holding a
training session for the entire fraternity at the beginning of the spring 2014 semester to
introduce them to the new system.
In this report, we discuss in detail the current situation with SigEp’s recruitment
system, opportunities for improvement, potential solutions and our implementation
strategy.
Phase One: The Survey Phase
Client Background
Sigma Phi Epsilon (SigEp) is a fraternity founded in 1901, and the chapter at the
University of Maryland was most recently re-established in 2003. It has grown its
membership over the years, currently standing at 98 members, making it the largest
fraternity at Maryland. As such, the organization attracts hundreds of potential new
members every semester for its recruitment week.
While the majority of recruitment takes place during one week, known as “rush
week”, the process is continuous. The entire membership is implored to recruit yearround and suggest potential members to the recruitment committee. The committee is
comprised of nine members, including the vice president of recruitment. The committee
has the ultimate decision of approving and extending bids to recruits to join SigEp.
The current system of monitoring recruits is a Google spreadsheet that is available
for read/write access to the recruitment committee. Recruits are categorized in different
colors: green for target recruits, blue for recruits approved for membership, and red for
recruits who have signed.
Problems With Current System
As we mentioned previously, the current system is only available for individuals
who are a part of the recruitment committee. This presents a number of problems to the
brothers and to the committee members. First, there could be potential biases amongst the
brothers who are on the committee. If the committee brothers do not like a certain
candidate, but the majority of the fraternity does, the candidate might not be accepted.
This would not be fair to the entire fraternity, and having a universally accessible
database would alleviate this problem. Another problem with the current format is that it
does not allow non-committee members to submit names of potential recruits on their
own. If a non-committee member wants to submit a name they would have to find a
committee member and tell them to put a specific person on the list themselves. This
would take time and effort, and by making the database accessible by everyone the
brothers will be able to submit names on their own, making the process more efficient.
When discussing the current system, the vice president of recruitment said a
major issue was the lack of accountability. If a committee member commits to a
particular recruit as his target recruit, there is not a clear way to note that and keep the
committee member accountable.
Looking from the perspective of a committee member, making the database
accessible to everyone would save time and effort for him as well. If a committee
member wants to gauge the overall thoughts about one person, not just fellow committee
members’ thoughts, he would have to go to each brother individually and ask them. By
giving all members access to the database a committee member would simply have to
sign in and see the overall rating or comments about a potential member that the
fraternity members have made.
Opportunities
There are many potential opportunities for this database system. In order to create
a more efficient system the database could be accessible either through the web or a
mobile device. If a brother meets someone who they believe could be a potential member
they could immediately submit the name via their phone or public computer instead of
waiting until they were at a computer with the saved database.
Another opportunity for the database would be to have potential members link
themselves to the system via Facebook. By linking their names through Facebook,
fraternity brothers would be able to see the potential brother’s profile, which would allow
them to learn more about the candidate (their hobbies, any mutual friends, etc.).
Third, with the new system, the fraternity could increase membership because
now everyone would be able to suggest candidates for membership. Since every member
could add to the recruitment list, there would be an increase in the number of potential
candidates, which may eventually lead to an increase in the number of actual members.
Lastly, the fact that the system could be accessible to all members would
undoubtedly create a higher sense of worth within the fraternity. Brothers would feel
more responsible and included by being able to voice their opinions directly, which could
boost morale amongst the brothers during the recruitment process.
Objectives
Our objective with SigEp is to create a transparent recruiting system that can get
both members and potential members more actively engaged in the recruiting process.
The new system would essentially be separated into three tiers.
Tier 1 will allow potential members to register as recruits in a central, secure
space, and give recruits the opportunity to share biographical information along with their
Facebook profiles with the fraternity. It will attract more potential members to the
fraternity and it will contain more broad information of potential members through
Facebook.
We also expect to see more active recruiting activities among general members
through Tier 2 of the system by empowering them to get involved in the recruiting
process. Tier 2 will allow general fraternity brothers to submit potential members’ names
as well as rate and provide general feedback on current recruits.
Finally, at Tier 3, the new system will give the vice president of recruitment full
access to the recruitment database, the ratings and feedback for each recruit, as well as a
new recruit assignment feature for committee members. With the new system he will be
able to easily assign recruits to each committee member and subsequently be able to
clearly see who is responsible for each targeted recruit, making delegation and
accountability much easier. Tier 3 will provide useful information to the committee in
order to make decisions, and we believe the decision-making process will be far more
objective than the old system since the amount of the source data would be more diverse.
The new system will increase the recruiting performance as the system will be
accessible by all the fraternity members (from nine current committee members to all
fraternity members). Therefore, our goal is to increase the number of applicants in the
database by 50% for the next recruitment season.
Project Scope
It is important to keep in mind the scope of this project, so that features do not get
out of hand and we can focus on what the client actually needs. The primary scope
includes a web interface and backend database to store information about potential
fraternity brothers. Different interfaces include one form for current brothers to input
new recruits, as well as a public form that prospective members can directly input
information about themselves into. Current brothers will be accessible to both a public
form and a private form but prospective members will not be able to see other applicants’
information.
Once student data is entered, the scope of the project is limited to tracking and
organizing student data by the recruiting committee. The actual voting of prospective
members will not be completed through this system. However, recruiting committee
members will be able to have prospective members assigned, where they can then move
them through different stages of the recruiting process. All of the described interfaces
will need to work on any Internet-connected device, including laptops, tablets, and
mobile phones.
Constraints
There are several constraints around the development of this system. The biggest
obstacle technically is the need for a web developer who is able to create custom form
interfaces and compile the required information in a database. Since student information
is being collected, security and privacy are an added concern. The database needs to be
secure so that student information does not get leaked. Privacy controls need to be in
place so that only the correct members of the fraternity can see their corresponding
information. There is a time constraint in that the system needs to be ready for spring
semester’s rush season, so the system needs to be complete by the beginning of January
2014.
Phase Two: Systems Analysis Phase
Description of Fact-Finding Methods: Observation
Of the various fact-finding methods our group used, observation was most helpful
for system analysis. Since one of the team members is an active member in SigEp, he was
able to directly observe the environment during recruitment week and note the system
and process being used for tracking students from applicants to recruits to approved
members.
Students can be added to the recruit database in one of two ways: they can register
online through the SigEp chapter website or on paper at a recruitment event. Information
that is required from the applicant includes name, phone number, year in school, grade
point average and school involvement. While these details come up in conversation at
recruitment events anyway, it is crucial to have the information in writing and trackable
so that the decision makers can be assured that they have accurate information when
assessing a recruit.
Once a student has registered, a member of the nine-member recruitment
committee enters the core information (name, phone number, year in school) into a
Google spreadsheet that is accessible by only those on the committee. At its nightly
meetings, the committee, led by the vice president of recruitment, reviews the database
and assesses each recruit’s interest level, his potential to fit in with the chapter, etc. The
committee ultimately decides if it should pursue the recruit further and, if so, which
member will be the lead recruit.
At each recruitment event, general chapter members are encouraged to meet
recruits and talk to them about the SigEp experience. If a general member feels that a
particular recruit could fit in well with the chapter, he is instructed to find a member of
the recruitment committee and introduce him to the recruit. On a given night, a
committee member can meet 20-30 recruits. Each committee member is tasked with not
only meeting recruits, but talking with them enough to assess their interest level and fit
within the chapter, and then being able to recall particular recruits at the nightly meeting.
Description of Fact-Finding Methods: Interview
In the early stages of the project, our team conducted an unstructured interview
with the vice president of recruitment so that we could better understand the current
system. From the interview we were able to understand the basics of the system, such as
what information is collected, and how the system has evolved from previous years. We
found out that the recruit database used to be an Excel document that was only accessible
on one computer, but now it is stored in the cloud as a Google spreadsheet.
Description of Fact-Finding Methods: Document Analysis
One of the most direct ways to analyze the current system was to look at the
Google spreadsheet being used to store recruit information and delegate tasks to
committee members. The vice president uses a color-coded coordination process where a
recruit marked in green is a target recruit that needs to be assessed further, blue is a
recruit that has been approved for membership but who has not yet signed his bid, and
red is a recruit that has signed his bid and joined SigEp.
Context Diagram
In the Context Diagram there are two external entities and one process for the
fraternity’s recruitment process.
An applicant gives his information to the committee via the Recruitment System
process. The Recruitment Committee adds their additional information to the system and
eventually the applicant will receive a recruitment decision via the process as well.
External Entities
Fraternity Applicants: This external entity represents any individual who has an
interest in joining the fraternity and who has filled out their information in the fraternity
sign-up sheets.
Recruitment Committee: This external entity represents the individuals who are a
part of the fraternity’s recruitment committee. These individuals oversee the recruiting
process and help manage the relevant recruitment documents.
System Inputs
From Applicant Agent
Applicant Information: From the Applicant to the Recruitment System process.
This data contains basic applicant information including name, year, credits and other
basic information.
From Recruitment Committee
Recruit Evaluation Data: From the Recruitment Committee agent to the
Recruitment System Process. These are data that are added to the Applicant Information
data by the recruitment committee. These data include a color-coding system, additional
information and which individual is assigned to the applicant.
System Outputs
To the Applicant Agent
Recruitment Decision: From the Recruitment System Process to the Applicant.
This data contains the recruitment committee’s final decision on an applicant's’
application.
To the Recruitment Committee
Updated Applicant Information: From the Recruitment System Process to the
Recruitment Committee. This information contains all information collected from the
applicants. This includes all original information provided by the applicants plus any
additional information provided by a committee member.
Data Flow Diagram: Level 0
Level 0 diagram outlines and explores the processes for “Register Applicants”,
“Transform to Google Spreadsheet”, “Color-Categorize Recruits” and “Finalize
Recruitment Decision”. These processes involve two entities and two data stores.
When the applicant’s application is received, it is recorded on the sign-up sheets
through the 1.0 process and then the information is transferred to the Google spreadsheet
via 2.0 process. The Recruitment Committee evaluates each applicant’s information and
the information does get color-coded thru 3.0 process. The updated information then
goes back to the Google spreadsheet after it gets color-coded. Finally, the Recruitment
Committee delivers the recruitment decision to the applicant.
Data Stores
Sign-up Sheet: This data store contains basic information of all applicants input
by the Applicant entity. This is a physical sign up sheet presented to the applicants at the
fraternity house
Google Spreadsheet: This data store contains the information transferred from
the sign-up sheet. The client currently keeps it on a spreadsheet very similar to Excel.
The information is identical to the information store in the Sign-up Sheet data store.
(All other inputs and outputs have been described in the Context Diagram)
Level 0 System Inputs
From Recruitment Committee
Core Applicant Information: From the Recruitment Committee to the
Transform to Google Spreadsheet process. This contains all information provided by the
applicants that will be sent to the Google spreadsheet
Updated Applicant Information: From the Recruitment Committee to the Color
Categorize Recruits process. This information contains all information collected from the
applicants. This includes all original information provided by the applicants plus any
additional information provided by a committee member
Color-coded Information: From the Recruitment Committee to the Finalize
Recruitment Decision Process. Contains the data from the color-coded Google
spreadsheet. This information will be used to make the final decision regarding new
applicants
Color-coded Information: From the recruitment committee to the Google
Spreadsheet data store. This is the color-coding that is put into the Google spreadsheet to
help the committee members clearly see who is eligible to come a new fraternity member
Level 0 System Outputs
To Recruitment Committee
Color-coded Information: From the Color Categorize Recruits to the
Recruitment Committee. Contains the data that has already been color-coded through the
process and returns the information to the committee members
Core Applicant Information: From the Register Applicants process to the Recruitment
Committee agent. This is the data that was originally provided by the applicants that will
be transformed to the Google spreadsheet
Data Flow Diagram: Level 1
This diagram explores the Register Applicants Process. The Register Applicants
Process can be exploded into two processes.
Process 1.1 Check Academic Year and Credit Requirement:
This process is responsible for checking each applicant’s eligibility in order to be a
fraternity member.
Process 1.2 Memo Important Information:
This process is responsible for inputting any important information of each applicant that
can be further evaluated by the Recruitment Committee.
Entity Relationship Diagram
The entity relationship diagram consists of two entities:
1. Applicant
2. Committee Member
A binary relationship exists between the two entities and the cardinality is 1 to
many in this case.
The primary key for Applicants is Name, and a foreign key of Recruiter Name connects
Applicants to Committee Members, whose primary key is Recruiter Name.
Phase Three: The Design Phase
Logical DFDs
Context Diagram
An Applicant will submit information about himself, his academic and athletic history,
and his school involvement. The Recruitment Committee and General Fraternity Member
will submit evaluations to the system, and the final output (Recruitment Decision) will be
sent back to the original Applicant
Level 0
An Applicant will be able to register on an online form that will ask the same information
the old system did. This information will be uploaded to a central back-end database. A
General Fraternity Member will be able to give recruit feedback via a custom solution
and this feedback data will be added to the recruit’s profile in the Recruit Database. The
Recruitment Committee will also be able to evaluate recruits, and with the final
aggregated recruit profile make the recruitment decision and tell the Applicant.
Level 1 – Process 3
The recruit evaluation process involves determining target recruits based on initial
interactions at recruitment events, and then assigning those target recruits to specific
members of the 8-person recruitment committee. These committee members continue the
conversation with their target recruits and determine their interest in Sigma Phi Epsilon
before the voting process begins.
Entity Relationship Diagram
The entity relationship diagram consists of the following entities:
1. Applicant
2. General Fraternity Member
3. Recruitment Committee Member
4. Evaluator
5. Evaluation
An evaluator is either a general fraternity member or recruitment committee member. He
creates an evaluation, which is identified by hi Evaluator ID and the applicant’s
Application ID.
CRUD Matrix
Applicant ID
First Name
Last Name
Academic Year
Number of Credits
Phone Number
Fraternity ID (general)
First Name
Last Name
Register
Recruits
Give Recruit
Feedback
CUD
CUD
CUD
CUD
CUD
CUD
R
Determine
Target
Recruits
Determine
Recruit
Interest
Level
Make
Recruitment
Decision
R
R
R
R
R
R
CUD
CUD
CUD
Fraternity ID (Recruitment
Committee)
First Name
Last Name
Recruitment Committee Role
Assign Target
Recruits to
Committee
Members
R
R
R
Evaluator ID
Fraternity ID
R
R
Application Evaluator ID
Application ID
Evaluator ID
Application Details
Decision
CUD
CUD
CUD
CUD
CUD
R
CUD
CUD
CUD
CRUD
R
R
R
R
CRUD
Candidate Systems Solutions Matrix
Characteristics
Visual Studio 2008
Microsoft Access
2013
Web Application
Oracle 10g
Portion of System
Computerized
Portion dealing with
processing input applicants’
information and rating
system, delivering final
decision and report
generation is computerized.
There is no physical output
under the system, all the
reports and decisions will be
electronically generated.
Same portion
computerized as candidate
1.
Same portion
computerized as
candidate 1.
Benefits
There is no initial purchase
price.
There is no initial purchase
price since the program
can be downloaded thru
TERPware (a fraternity is
a university affiliated
philanthropic organization,
using TERPware does not
break conditions).
Maximum
Blob/Clob size and
Database size is
unlimited. It is
compatible with
Windows, Mac OS
X, Linux, UNIX
and z/OS
Servers and
Workstations
Visual Studio 8, SQL Server
Express and Windows 2000
MS Access 2013, SQL
Server Express and
Windows 2000 (using the
SQL Server Migration
Assistant for Access)
Oracle WebLogic
Software Tools
Needed
Must have Windows 2000 or
above and it requires the
.NET framework and
Windows Installer 3.0 or
above. Visual Studio 2008 to
create in the configuration of
databases.
Must have Windows 2000
or above and it requires the
.NET framework and
Windows Installer 3.0 or
above. MS- Access 2013
to create in the
configuration of databases.
SQLTools 1.5,
Oracle 10g Forms
Builder and Toad
Data Modeler. Both
Windows OS and
Mac OS X Server
can be used.
Application
Software
Visual Studio
MS Access
Oracle 10g Forms
Builder
Method of Data
Processing
Client/Server
Client/Server
Client/Server
Output Devices and
Implications
No physical output other
than electronically generated
information and reports
Same as Candidate 1.
Same as Candidate
1.
Input Devices and
Implications
Laptop (for members at
recruiting event) or
applicant’s own device
Same as Candidate 1.
Same as Candidate
1.
Storage Devices and
Implications
MS SQL
MS SQL
Oracle DBMS
Feasibility Analysis Matrix
Feasibility
Criteria
Wt.
Visual Studio
2008 (Custom)
Microsoft
Access 2013
Web
Application
(Custom)
Oracle 10g
(Custom)
Operational
Feasibility
How well
proposed
system solves
the problems
and takes
advantage of
opportunities
identified during
the scope
definition and
problem
analysis phases
How well
proposed
system satisfies
system
requirements
identified in the
requirements
analysis phase
10%
This solution
offers an
opportunity for
information to be
electronically
stored. Also the
reports and
decisions will be
electronically
generated
through use of
Visual Studio
2008.
This user-friendly
web-based
application will
be a selfexplanatory for
both committee
members and
potential
members.
SQL Server
Express would
be more
operationally
feasible than
Oracle WebLogic
Score: 100
This solution
offers an
opportunity for
information to be
electronically
stored. Also the
reports and
decisions will be
electronically
generated
through use of
MS Access.
This userfriendly webbased
application will
be a selfexplanatory for
both committee
members and
potential
members.
SQL Server
Express would
be more
operationally
feasible than
Oracle
WebLogic
Score: 100
This solution
offers an
opportunity for
information to be
electronically
stored. Also the
reports and
decisions will be
electronically
generated
through use of
Oracle generated
web-based
application.
This user-friendly
web-based
application will
be a selfexplanatory for
both committee
members and
potential
members.
Managing Oracle
WebLogic Server
system is
relatively
challenging
compare to SQL
Server Express
Score: 95
Technical
Feasibility
Is the proposed
technology or
solution
practical?
Do we currently
possess the
necessary
technology
Do we possess
the necessary
technical
expertise?
40%
Our team is
capable of
producing a
Visual Basic
based web
application within
the scope of the
project.
Solution requires
writing
application in
VB.NET. Our
team has some
experience in
VB.NET, and it
should be
relatively easy to
be implemented.
Score: 95
Our team is most
capable of
producing an
Access based
database
management
system, however
we have no
experience in
converting
Access DBMS
into a web
application.
Solution requires
writing
application in
VB.NET. Our
team has some
experience in
VB.NET.
Score: 90
The solution
requires
comprehensive
knowledge in SQL
language, and our
team has some
experience in it.
Our team does not
have any
experience in Oracle
WebLogic Server
system.
Our client is
concerned about
managing WebLogic
server system.
Score: 85
Economic
Feasibility
40%
No purchase cost
for a developer or a
Same as candidate
1.
Same as candidate
1.
Cost To develop:
personal use
Score: 100
Score: 100
2-3 months
1-2 months
3-4 months
Score: 95
Score: 100
Score: 90
97.5
96
92.5
Score: 100
Schedule
Feasibility
An assessment
of how long the
solution will take
to design and
implement.
10%
Ranking
100%
Rationale for Weights
Below we have listed the four types of feasibility listed in our feasibility matrix along
with their respective weights and the justification for these weights in the context of the
Code Enforcement Division.
1. Economic Feasibility
a. Weight: 40%
b. Justification: This category is weighted as the top two highest due to the fact
that our client is a school fraternity organization and our first goal is to provide
the system at no cost. All three candidate systems are free for a developer and a
personal use.
2. Technical Feasibility
a. Weight: 40%
b. Justification: Technical feasibility is closely correlated with economic
feasibility. Since our first goal is to provide the system at no charge, the project
scope has to meet our team-members’ experience and knowledge in programming
languages and other technical expertise.
3. Operational Feasibility
a. Weight: 10%
b. Justification: We expect our new system to be as simple as possible with few
external users and offer minimal relational database management function. With
the system’s simplicity, we decreased the weight of the operational feasibility to
10%.
4. Schedule Feasibility:
a. Weight: 10%
b. Justification: Since our client has some time until the next recruitment rush
season, we have decreased the weight of the schedule feasibility to 10%. Since
our team members do possess some experience and knowledge for the program
logic and languages, we expect to produce the new system within a relatively
short period of time. The implementation period will be very short and it would
be almost an immediate once we deliver the program. Most of our scheduled time
will be spent for a program debugging process. This system is not critical to the
fraternity, so in the case of a delay, the current recruitment system could be used
for an additional semester as the new system is being completed
Physical DFDs and Error Report
Context Diagram
Level 0
Level 1 – Process 3
Input/Output Forms
Recruitment Application:
Assign Recruit to Fraternity Member
Implementation
In terms of the actual implementation of our new recruiting system, we plan to
have the new system fully functional by the next recruiting session. Because the process
of recruiting new members to the fraternity only happens twice a year, the new recruiting
system will be relatively easy to implement. Also, because the recruiting system only
holds data for the current recruiting semester, any previous data can be disregarded
because the information will be irrelevant. Therefore the fraternity will not have to deal
with the time consuming process of transferring data from the old excel spreadsheet to
the new web-based system.
At the beginning of the next recruiting semester the fraternity will completely
disregard the old system and only use our new one. Since the new system is much more
advanced and user friendly, the old system will essentially become obsolete. Members
will now have access to the recruiting information wherever there is an internet
connection and there will no longer be a need for an excel document with all of the
recruiting information.
In terms of training, the new web based system is very easy to navigate and
understand with little to no training. With a very simple user interface, the system will
not take long for the fraternity members to learn and it will be a smooth and easy
transition. At first, it may be a good idea for the members of the recruiting committee to
have a brief testing period just to get a feel for the system and so that they can get a
firsthand look at how the system has improved and what changes were made. After the
committee is done with their testing period, a brief training session should be held with
the entire fraternity to help all members understand the changes in the recruiting process.
But again, the new system is very easy to learn and the entire training process should
only last a couple of hours at most.
Lessons Learned
Throughout the entire semester, not only did our entire team learn a lot about
analyzing, designing and implementing a new IT system, but we also learned a
tremendous amount about how to function and be successful as a team.
This was the first time any of our group members had to design our own
information system, and at the beginning of the project we did not realize how much
detail would be involved. For instance, when we were thinking about what our data flow
diagram would look like for the old system we had originally assumed that there would
only be one data flow and one process. As we examined the old system with more detail
we realized that there was in fact many more data flows and processes involved with the
system. Each time a document was composed or transferred within the old system a new
process would be created. Seeing how much detail was involved with the design of an
information system opened the team’s eyes, and we were able to see that it takes more
than just a good idea in order to build a proper information system. Furthermore, the
feasibility analysis helped enforce this idea. Many times our group would come up with
what seemed like a great idea, but when we took the time to think about how feasible the
idea really was we determined that it would just not be practical. This extra attention to
detail helped our team, and we were able to come up with ideas that were well thought
out and practical in use.
Additionally the group was able to learn how to stay organized and on schedule
even though each group member had a different schedule and availability. The project
was completed in sections and each section had a very strict deadline. With 4 group
members, all of whom had different class schedules, we found it very difficult at first to
find a specific time where each one of us was available to meet. We quickly learned that
if we were going to succeed as a team we needed to be timely and organized. When our
team did have a chance to meet, specific deadlines were made within the group and each
member made a conscious decision to have their share of the work done one time and
with high quality. Working in an environment that forced us to stay organized will be
tremendously beneficial for each one of us as we progress through our young careers.
Many, if not all, projects have strict deadlines and the fact that we were able to learn how
to properly set our priorities will give us an advantage when we enter the workforce.