1. Latinas Revisited: A “Database Project” Became a “CRM Project”
The Fantastic Five (Spring 2007)
Tracy Ma, now at Flowserve in Dallas
Zakria Malik, Hewlett-Packard, Austin
Robin Moore, Simpler-Webb Inc., Austin
Gretel Paronzinni-Fredette, Deloitte, Austin
Aaron Thompson, KPMG, Dallas
This was a spring 2007 project for Angie Ayala, a 2003 UT MIS grad who is now a Systems Analyst II at the Texas Optometry Board here in Austin. This project is for Latinitas, a non-profit organization where Angie is an officer on the board. These 17 slides (shown on Day 2 in MIS 374) were originally presented by the team for their end-of-semester project presentation to class.

2. Agenda Latinitas background & major project goals
Our biggest challenges / difficulties
Our key decisions and solutions  
Lessons learned from the project

3. Latinas
You can read about the purpose of Latinitas on their webzine,
“Latinitas is a non-profit organizatin focused on informing, entertaining, and inspiring young Latinas to grow into healthy, confident, and successful adults.”
Their mission is “to empower Latina youth through media and technology.”
More than 70 volunteers help with the magazine, training activities, and fund raising.

4. Latinas
This is the volunteer web page on their public site (their extra net).
Volunteers are critical for Latinitas—they have no paid part-time or full time staff.

5. More than 70 volunteers currently help with the magazine, training activities, and fund raising.
Managing so many volunteers is not easy. Nor is fund raising to support so many activities.

6. Latinitas Donation System – As Is
Donors Information
Volunteers contact donors to request donations for a particular event based on previous history and keep records on various forms – by hand, spreadsheets, etc.
Management reports on donors for events are not
easily accessible.
From Problem Chain Analysis
Main Problems:
Information System: Organization does not have a business intelligent information system in place to document and store business process information.
Business Process: Structured procedures are not in place.
Volunteers record donations on various forms and send Thank-you letters to donors.

7. Latinitas Donation System – Proposed
Donors Automated Database
Volunteers contact donors to request donations for a particular event based on reports or system searches. Volunteers enter donor’s information by filling in easy-to-use screens.
Management reports and searches on donors are available for events and date ranges.
From Problem Chain Analysis
Information System (Objectives):
Create a donor’s database
Database should have user friendly graphical interface
Database should have reporting capabilities using different criteria and filters
Volunteers record donations on centralized database and send Thank-you letters to donors by using templates stored in the database.

8. Original Project Scope Creep Doubled in size MS-Access
Volunteer Database • Keep track of volunteer information o Volunteer Information o Volunteer Schedules o Reports o Search capability o Editable database with GUI
MS-Access
Doubled in size
Donor Database
• Keep track of donor information
o Donor Information
o Donor Status
o Donor Interaction
o Track Donations
o Reports
o Search capabilities
o Editable database with GUI
SQL DB + WEB GUI
Scope Creep

9. Functional Requirements
Create a Donors database
The Donors database will collect information concerning:
Organization/business
Contact person at organization/business
Contributions
Solicitors
Follow-ups
Develop a web application that includes the following items:
Database searching capabilities
User should be able to search database using grid view with sorting capabilities and search fields. The fields to include on the grid view are:
ConstituentType
OrganizationName
ContactFirstName
ContactLastName
City
State
ZipCode
Active
Notes (from tblConstituents)
CampaignID
GiftType
GiftSubtype
Value
Campaign
Appeal
Database reporting capabilities (including letters):
Donors who donated to a specific event sorted by donor. Fields to display: Event Name, Donor, Amount Donated, Donation Type, and sum of all donations and amounts
Donors who made a donation during a specific period of time, sorted first by event and then by donor. Fields to display: From date, To date, Donor, Event, Donation Type, Amount Donated
Donor’s contact person. Fields to display: Organization, Individual, Contact Person, Contact Information, , Mailing Address, Phone, Cell Phone
Mailing Labels. Fields to print/display: Organization, Contact Person, Mailing Address
Donations Received, ordered by event. Fields to display: Organization/Individual, Event Name, Date, Amount Donated, Donation Type.
Database insert/update/delete capabilities for donors and donations tables
User friendly graphical interface
Login capabilities to accommodate 3 levels of access
Administrator: full control  view, add, modify, delete, print reports
Management: everything the administrator does with the exception of deleting records from databases
Employees: should only be allowed to search for data and to print reports
Employees do not add, modify, or delete records on the table
Develop the needed tables to grant access to different users to the application/database.
Provide Angie with documentation regarding how to add/delete/modify records on the login database using SQL
Help menu capabilities on website
The current help menu on the prototype should be accessed by Angie only
There should be a second help menu for the rest of the users that allows them to view the documents, site map, and Angie’s
Ability to upload more documents in the future under the help menu
Create Customer Relationship Management (CRM) module
Send Thank You letter
Send Request for Donation letter
Create tracking for letters sent
Create tracking for sent
Create tracking for phone calls made
Scope Stampede
Our analysis phase revealed that the scope was GYNORMUS!
Looking at the results of our analysis of detailed requirements was a puzzler for us.
Aaron and Robin observed that the requirements we’d developed were closer to a request for a CRM application rather than a “Donors database.”
What we imagined first talking with Angie about her “Donors database” request was tiny and VERY DIFFERENT from CRM application.
Our analysis (problem chain, DFDs, requirements list, etc) led us to a much clearer sense of what is really needed. Angie, our user, was super to work with, but also super busy. None of us saw what we were really looking at until we went through the analysis required for Delivery 1. 9

10. Scope, Time, Resources Conclusion: Cut the Scope Scope = Gynormous
Time = Fixed
Resources = Limited
(5 MIS Students with no organizational support)
Options:
1. Reduce scope -> code for only a component providing very little functionality
2. Come up with more resources. HOW?!? Team thinking….
Conclusion: Cut the Scope

11. Scope, Time, Resources Team Thinking… Scope = Gynormous Time = Fixed
Resources = Limited???
Options:
1. Reduce scope -> code for only a component providing very little functionality
2. Come up with more resources. HOW?!? Team thinking….
Team Thinking…

12. Thinking – How to draw 4 lines & connect all dots ?
Outside the box
Inside the box
Open Source
Thinking Inside the Box
Problems:
1. Time constraints
2. Only 5 people to develop code
3. Team did not want to fail Latinitas
Thinking Outside the Box
Solutions: Team keeps thinking BUT outside the box!
Gretel went into a panic attack mode, but did not freeze. She pumped lots of adrenaline and fired an to the team asking to do some research. Research for an off the shelf CRM applications that can be customized (increasing resources) AND at the same time keep working on coding for only one component (cutting scope). Reasoning: the time constraint was a constant pressure on the team. Thus, if off the shelf application was not found OR it did not work, then the team could fall back to coding for only one component.

13. Found free software & eliminated programming!
Eureka!
Found free software & eliminated programming!
We investigated free solutions and Robin found an open source CRM designed for non-profits. Eureka! 13

14. Eureka!
CiviCRM had a components that looked perfect for our client’s top priority goals.
Team at a decision point: do we go for it and change all our documents OR do we keep working on one component? Team weighed the risks of the new application as well as time constraint.
Solution: Robin to install the application on a paid server and run a test environment for 1 week (extra time earned on analysis phase) while rest of the team assessed % of original requirements to be fulfilled by customizing CiviCRM for Latinitas. If (Robin succeeded AND (the % of fulfilled requirements > than % fulfilled by coding for one component)) then team would embrace new application and modify documentation.
In the meantime, team gained buy in approval from Latinitas for CiviCRM as a solution for Latinitas. ***Angie asked the team why is it that all of a sudden they changed from a custom made to an off the shelf application. The team replied that it was not until they finished their analysis that they realized that Latinitas needed a CRM application vs a Donor’s database.*** Often times you will find that not even the user knows what they really want!!! You have to literally pull the requirements out of the client! 14

15. Cut Scope – even with open source software CiviCRM
Eliminate mass mailing features --
export .csv file instead
Eliminate automatic and mail tracking -- Only track thank you letters
Reduce access control from 3 levels to 2
Reduce number of searches/reports
Prioritize in-scope requirements
Determine critical path
If you remember from our previous slide, the team was forced to originally cut the scope to determine what could be accomplished by 5 programmers. At the same time, the team was also researching for an off the shelf application hoping to find something that would fulfill the majority if not all the requirements. They did not want to promise Angie something that they could not deliver. Thus, the team resorted to cutting the scope and prioritizing the rest of the requirements. Angie and the team agreed to implement that strategy because they had to manage the requirements and ultimately, the project. The team had to know what to work on first if they were running out of time and only a few requirements could be accomplished. In the end, all of the prioritized requirements were completed because CiviCRM provided all the needed resources. The only item that was not implemented as suggested was the access control (only one given). This is because the content manager, Joomla, did not allow CiviCRM to have this functionality (as Drupal did). However, Joomla was Angie’s decision since she had to take over the maintenance and administration of CiviCRM.
Lessons to pass on: Your reputation and credibility are at stake! “It is better under promise and over deliver, than to over promise and under deliver.” If you want to be successful in this business you have to build a good rapport with your client. 15

16. Phased Development P A D C
Figure 3.6, p. 178
Phased Development
Our Delivery 1 work led to a new view and an open source software solution.
Preliminary investigation
Analysis
Design
Preliminary construction
Final construction
System test and installation
User Review
Cut Over: Put system in production P D C A
But we still had lots of tasks to get this into production for Latinitas !!

17. More Analysis, Design, & lots of Construction
Cutting the scope took away a large part of the system’s functionality
Search for a solution
SourceForge.net
Wikipedia Open Source List
inWent
Google
Finding a web host
After 4 installs, found byethost
Learned PHP
Robin went through series of installations and servers. Problem: Discrepancy between stated system requirements and actual requirements. CiviCRM uses more memory than most web hosts allow. Robin succeeded after all but server was unstable.
Team was already in the process of redoing all documentation, preparing testing plan, testing data, and actually testing Robin’s 4 installations! Team put together training for Latinitas and wrote user as well as administrator manuals.
Team completed approx 95% of the requirements by installing CiviCRM (all modules), the open source application. In reality, CiviCRM fulfilled 100% of the requirements. However, the team was only able to customize 95% by the due date. Angie Ayala agreed to customize the other 5% at a later time. (The mass mailing feature (CiviMail) was installed but left to Angie to configure. Instead, the team provided with a CVS file that Angie could export to MS Word and do mail merge.) 17

18. Latinitas Project Conclusion – Users’ View
Donors Automated Database
Volunteers contact donors to request donations for a particular event based on reports or system searches. Volunteers enter donor’s information by filling in easy-to-use screens.
Management reports and searches on donors are available for events and date ranges.
From Problem Chain Analysis
Information System (Objectives):
Create a donor’s database
Database should have user friendly graphical interface
Database should have reporting capabilities using different criteria and filters
Internal Donor functionality achieved
Volunteers record donations on centralized database and send Thank-you letters to donors by using templates stored in the database.