1. Date and Location
1.1. Thursday, Jan 17th from 11AM to 1PM CST
1.2. City Offices
1.2.1. 809 N. Broadway, Milwaukee, WI
1.2.2. ITMD Large Conference Room, 4th Fl.
2. Participants
2.1. Milwaukee
2.1.1. Nancy Olson
2.1.1.1. CIO
2.1.2. Alicia Amerson
2.1.2.1. Contracted City PM
2.1.3. Michael Drzewiecki
2.1.3.1. Procurement Specialist
2.2. Accela
2.2.1. Rob Casseti
2.2.1.1. VP of Sales
2.2.2. Drew Arnold
2.2.2.1. BDE
2.2.3. John Cross
2.2.3.1. Services Manager
3. Parking Lot Ideas
3.1. Tiered pricing
3.2. Get the City to invest $15K in an SOW workshop that enables a senior Accela person to go on site perform a week of analysis against the RFP to determine an SOW that will be the list of deliverables for both teams.
4. Internal Questions to Answer
4.1. What are people's itineraries?
4.2. Scheduling prep meeting in Milwaukee
4.3. Has the new pricing plan been finalized?
4.4. What's the status of the tiered pricing discussion?
4.5. How do we position progress payments?
5. Potential SOW Discussion Topics
5.1. Number of processes we'll configure vs. them
5.1.1. In the RFP we said we'll handle..
5.1.1.1. 12 high complexity processes
5.1.1.2. 24 medium complexity processes
5.1.1.3. 24 low complexity processes
5.2. Confirm the full 16 interfaces in RFP are actually required
5.3. What will they take on from a PM perspective
5.3.1. Weekly status reports
5.3.2. Updating items in Sharepoint
5.3.3. List management
5.3.4. Risk management
5.3.4.1. Communication
5.3.4.2. Related follow-up
5.4. Can they take a train-the-trainer approach
5.4.1. Admin
5.4.1.1. Accela Automation
5.4.1.2. ACA
5.4.1.3. Accela Mobile
5.4.2. End user
5.4.3. Scripting
5.4.4. Major benefit of train-the-trainer is user buy-in
5.5. What level they will take on in UAT
5.5.1. The extent they can take on UAT will be influenced by the degree they can take a train-the-trainer approach.
5.6. Number of reports Accela does vs. City
5.6.1. In the RFP we said we'll handle..
5.6.1.1. 10 high complexity reports
5.6.1.2. 10 medium complexity reports
5.6.1.3. 50 low complexity reports
5.6.2. Options
5.6.2.1. 5 day course with City taking more medium & low complexity reports
5.6.2.2. 2 day course with Accela taking more medium & low complexity reports
5.7. Positioning Progress Payments...
5.7.1. Reduces Administrative Time – Fewer invoices requires less paperwork and processing time. Agency signoff is required on all deliverables regardless of the payment schedule type, however, there is significantly less time spent negotiating signoff on the deliverables.
5.7.2. Reduces Cost – Less Accela and Agency project management time is required to manage the project under a progress payments schedule which results in real dollar savings for the Agency.
5.7.3. Increases Focus – Separating payment from deliverable signoff allows all project team members, including Agency and Accela Project Managers, to focus on ensuring the highest level of quality.
5.7.4. Increases Teamwork and Flexibility – Implementing a new system is a collaborative effort. Teamwork is imperative to the success of the project. Progress Payments encourage teamwork by removing the tendency to struggle over signoff of each deliverable and allows more flexibility to do what is right for the Agency without the restraints of signoff language for each deliverable.
5.7.5. Combine PM discussion with Project Payment discussion
6. Stuff That's Been Done
6.1. Submitted to Milwaukee Accela redline edits to Milwaukee master services agreement
6.2. Received responses to our clarification questions.
6.3. John Cross updated services pricing on 1/8
6.3.1. Changes made in the following areas: • Project Management • As-Is Analysis • Scripting • Conversion of .Net applications (presuming the City can provide consolidated files that accommodate conversion needs for multiple data sets due to the use of the same platform) • Conversion – Code Enforcement – make the city do more work once they have been trained on Conversions • Conversion – Permitting – make the city do more work once they have been trained on Conversions • GIS
6.3.2. Be aware we have no allowance for post go-live support. That is an implementation risk
7. Stuff That Needs To Be Done
7.1. Internal
7.1.1. Finalize first draft of SOW
7.1.1.1. Remove deliverable based payment language
7.1.1.2. Include first version of progress payment table with value props
7.1.2. Finalize user plan pricing
7.1.3. Determine what subscription pricing Energov has been offering in its RFP responses.
7.1.4. Finalize tiered pricing
7.1.5. Submit 1st draft of SOW
7.1.6. Create order form
7.1.7. Submit order form
7.2. External
7.2.1. Negotiate final SOW
7.2.2. Negotiate final Services Agreement
7.2.3. Agree on final on-going subscription pricing
7.2.3.1. Negotiate term
7.2.4. Agree on user count required for implementation
7.2.5. Sign contracts
7.2.5.1. Order Form
7.2.5.2. Services Agreement