Sofware Program Planning and Implementation at a Complex Non-Profit

Posted by Robert Merrill on November 22, 2008 under Client case studies | Be the First to Comment

A uFunctional LLC Client Case Study

Situation

In Spring 2007, the Archdiocese of Milwaukee (ArchMil) and Saint Francis de Sales Seminary (SFS) were beginning a major re-organization. Some organizational processes were being eliminated, others consolidated, and still others moved to units that did not yet exist.

The IT staff of ArchMil and SFS is responsible for infrastructure and utility applications–network, file and print, and staff desktops including productivity applications and email. Scattered custom applications were created and maintained by organizational units to serve their own purposes. This approach to IT governance is fairly common.

One such application was an Access database, developed over a period of about ten years by SFS staff and various contractors. Different people knew and used different parts of it, but no one knew it all.

The coming organizational changes required that this application and its data be divided. In addition, it had a large maintenance and enhancement backlog.

ArchMil and SFS are long-time clients of Northwoods Software Development, of Brown Deer, WI. The ArchMil Intranet and Extranet run on Northwoods’ Titan platform. Northwoods specializes in larger projects, but the SFS database appeared to be a small project, wrapped in a complex context. Northwoods wanted someone who could cover all roles, from high-level software program planning down to Access remediation, refactoring, and new work, so they brought in Robert Merrill, Principal of uFunctional LLC.

Creating a Roadmap

Robert’s first step was to review the SFS Access database with its primary users, determine what functionality was actually being used to support what processes within SFS, and infer dependencies from the underlying data. In requirements interviews, people naturally focus on the primary functionality. When breaking a system apart, it’s important not to overlook dependencies that individual users may not even be aware of. Robert uses Function Point Analysis (FPA) to detect these quickly. Though primarily for quantifying scope and estimating projects, FPA verifies completeness of functional requirements as a side benefit.

Robert then reviewed the primary functions with ArchMil and SFS leadership. Which processes were staying put? Which were moving elsewhere within the organization? Which were shifting to the new John Paul II Center? What pieces of the SFS Access database needed to go where, and by when?

Visual representation of something this complex is vital, so Robert prepared a tablecloth-sized Roadmap, consisting of a series of Phases (organizational states) with intervening Transitions (information system changes).

Roadmap for the SFS Access Database (white, at left), and the three replacement Access databases. Two of them (Transcripts and Deposit Transmittal, shown in gray) remained within the Seminary, while the third (MFI Database, blue) was extracted and enhanced to support a new organizational unit within the Archdiocese. The roadmap was revised regularly—this version is from Transition B planning.

Planning the Transitions

The original Seminary Access Database spanned a large functional scope. The roadmap made it easy for Robert, and ArchMil and SFS leadership, to divide its functions into four categories:

• Functions not presently being used
• Functions supporting organizational processes that were about to cease
• Functions supporting processes remaining within SFS
• Functions supporting ongoing processes being transferred outside SFS

With this information, the three replacement applications shown on the roadmap practically scoped themselves.

Implementation

Because Robert did the functional analysis and was involved in all planning, no handoff to a technical person was needed, and implementation was straightforward and efficient.

Robert and the three affected organizational units selected an agile delivery methodology, with Robert presenting running software with new features every week, and Archdiocese and Seminary staff verifying the correct operation of the new features, and clarifying requirements and providing examples for the next set of features on the list.

Near the end of the project series, another Archdiocese group came forward with a fourth project–remediation and enhancement of a small application based on an earlier version of the Seminary database. Robert’s growing experience with the Seminary, the Archdiocese, and the old database made this implementation go quickly as well.

A Supporting Role

As noted above, Northwoods specializes in larger projects. By Spring 2008, one of these was getting underway at ArchMil–a rewrite of a thirty-year-old pension system called LPP. Because of Robert’s expertise with early-stage project estimation, Northwoods involved him in the initial meeting about LPP requirements. Rather than interviewing subject-matter-experts and management independently, Robert led the whole group of about a half-dozen people through a two-hour facilitated session, which produced a functionality context diagram of LPP, on poster paper taped to the wall in the meeting room.

Model of the functionality (white) and referenced and maintained information (yellow) of the legacy LPP system. The functional scope boundary is shown in red. Potential scope enhancements are shown with dashed red lines. With Robert’s facilitation, the users of the LPP system and their manager developed this model in about two hours.

From this model, Robert was able to prepare a Function Point count and initial estimate for the rewrite.
Robert was then asked by Northwoods to work with the maintainer of the legacy system to extract and characterize the subset of data which would be needed to develop the replacement. Using the data-mapping capabilities in Access, Robert developed a largely automated extract-and-transform tool that allowed ArchMil subject matter experts and the Northwoods design team to verify that the necessary data were present and that the business rules were properly understood. The Northwoods team then quoted and completed the rewrite, with Robert’s assistance with data ETL (Extract, Transform, Load).

Summary

On large software projects, it’s common to support the programming team with specialists—project managers, business analysts, and database administrators. Their work is often preceded by that of an application development manager or CIO—someone who is able to work with the organization’s executive team to develop a software roadmap to support organizational change.

This case study is intended to illustrate uFunctional’s ability to provide small projects with the support of these multiple roles, because of Robert Merrill’s diverse background and broad range of skills.

Acknowledgements

Robert would like to thank the management and staff of the Archdiocese of Milwaukee and Saint Francis de Sales Seminary for their willingness to contribute to this case study, and for their essential roles in making this program a success.

Robert would also like to thank Northwoods Software Development for entrusting him with a central role with one of their oldest and most important clients, and for their permission to write and publish this case study.