Everything looks like a failure in the middle

Posted by Robert Merrill on August 27, 2009 under Change Leadership, Client case studies | 2 Comments to Read

I’m involved in one client project right now where no one’s happy.

My relationship with this client is long-term and (fortunately) transcends this particular project. I was pointed at it last Spring to help get it back on the rails. The project manager and I came up with a problem frame—a container of the right size and shape to fit all of the seemingly random questions we were being asked—and identified several parallel work streams to make progress on all fronts.

We’re working cross-functionally within the organization, so there are relationships to be established and the concerns of bosses’ bosses to be discovered, sometimes the hard way. We’re working with new outside vendors, so there are negotiations and promises and documents and lawyers to review it all.

It’s really a research project, disguised as an information systems project. I used to be a research scientist, so I’m familiar with the feeling of pursuing a line of research that I know will pay off. But that’s not the client culture, and I understand that.

But the sponsor is frustrated. The team is frustrated. I’m frustrated.

So it was with relief that I read about Kanter’s Law: Change is Hardest in the Middle. Rosabeth Moss Kanter, a named-chair professor at the Harvard Business School, puts it like this; “Everyone loves inspiring beginnings and happy endings; it is just the middles that involve hard work.” Read more of this article »

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


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.

“Robert Merrill has been a pleasure to work with.  I found him to be very insightful and thoughtful in his work.  I was pleased that he talked through situations and suggested solutions that he believed would truly fulfill our needs while always looking at the cost/benefit factors.”

Chris D’Amato, Accountant, Saint Francis de Sales Seminary

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 and the three replacement Access databases
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.


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.

“After reading the case study I realize it was the smallest part of your ArchMil work but I always felt you gave it importance, and never let it drop off the to do list. You always worked on the CFC project and came back with revisions for me to review. I have worked with other programmers who only worked on the squeaky wheels. It was refreshing to see your weekly e-mail and know that work had been done. Thanks!”

Cris Hauck, Accountant, Archdiocese of Milwaukee

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.

Context Diagram of the legacy LPP system
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.

“Your development of the map of the LPP system was well-done and allowed the project to move forward quickly. We very much appreciated the skills you brought to our projects and the significant contributions you made to the success of the projects.”

John Marek, Chief Financial Officer, Archdiocese of Milwaukee

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).


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.

“Personally, I appreciated your ability to listen to what I as management required in terms of utility; to hear the functionality that the office staff required in order to input/access data, and the knowledge and wherewithal you used to integrate the two. We got what we needed, the way we needed it!”

Deacon John Ebel, Director of Diaconate Formation, Archdiocese of Milwaukee

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.


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.