Cumulative list of lessons learned from the self-service password reset project

Date

Lesson Learned

(Optional) Comments

02/17/2011

The detail required in the software requirements specification document caused a delay in getting the project scope approved to the point where software development was well on its way to completion before all project planning was completed.

In the future complete requirements as much as possible before spending time developing use cases so the project scope can be approved by the sponsor.

04/01/2011

Better involvement and participation from all developers in creating, analyzing, and finalizing use cases would put all developers "on the same page" before any code is written.

Development work began from the high level requirements of the software specification document before the use cases were fleshed out. This caused differences in interpretation of exactly how the system and workflow should work.

04/19/2011

There were many hours spent discussing the user interface for the account recovery options (called Account Manager). Many personal opinions, likes and dislikes were rehashed multiple times and the interface redesigned more than once.

Do a quick prototype of the user interface or clearly communicate and example interface to the UI development team before software requirements are complete.

05/20/2011

Account Manager improvement

Shortly upon completion of this project discussion of how to improve Account Manager should begin. How can we collect feedback, how can it be improved and made better, etc.

06/13/2011

There are loose ends to clean up but overall this project is considered to be VERY SUCCESSFUL

 

06/13/2011

All developers should have met prior to writing use cases and writing a detailed requirements specification

 

06/13/2011

For future projects consider rapid prototyping the user interface for initial approval before development begins

 

06/13/2011

This project did a lot of detailed planning then was deep into development before the user interface was released/shown for comment. That approach did not allow for easy changes to the user interface (or workflow) because developers were too far along by then and deadlines were looming.

 

06/13/2011

As the release date approached 4Help should have become more involved and communications/documentation meetings should have been regular.

 

06/13/2011

The goals of the project were accomplished, however, there was an unwritten goal of satisfying an Internal Audit comment that was also accomplished.

 

06/13/2011

In the future, in order to evaluate "success" metrics should be developed as part of the project that will quantify success, e.g., within 6 months of deployment the number of 4Help calls for PID password reset should decrease by 25%. Some creativity may be needed if a goal is to "allow" users to reset their PID password, because the users choice could be not to do it, so how do we determine/ measure success?

 

06/13/2011

Software deliverables were completed. There was inadequate documentation at rollout. In the future include documentation as a specific deliverable.

 

06/13/2011

A deployment strategy needed to be developed. In the future a deployment specification document should be produced and communicated with project stakeholders.

 

06/13/2011

An unforeseen benefit of this project is the availability of Short Message Service (SMS) messaging (text message) as an option for all IT projects.

 

06/13/2011

Long distance calls to users using the Interactive Voice Response (IVR) service were not included in project budget estimates.

Greg will update the budget for project closing to reflect an estimate of long distance charges

06/13/2011

One project problem area was dealing with contracts. Specifically the contract with bulletin.net for SMS service was held up in the VT legal department for months. For future projects that deal with VT Legal use a deadline that you are comfortable with not a real deadline when the contract is actually needed, i.e., provide lots of lead time.

VT Legal office was tied up with higher priority, university business that stalled signing of the final contract.

06/13/2011

Since there is no way of telling who (or what department) will consider some part of a project a FERPA issue (e.g., requesting information from students) allow plenty of lead time to address those concerns.

Part of the delay with VT Legal involved the university registrar (Wanda Dean) who was questioning the request and possible storage of student cell phone numbers