Case Study: “Planning the Needs of Other Organizations”
If you think a thorough, high-quality needs analysis is daunting on an internal project, imagine if you were an HRIS vendor and your job was to provide a best-of-breed system (see Chapter 2) that meets most of your many different clients’ needs. Such an approach makes planning and needs analysis more challenging because difficult choices must be made as to the functionality that is sufficiently broad to go into a general market package. It is costly to vendors, and indeed may be infeasible, to include functionality that is so specific that only a small portion of a system’s client base benefits from the function.
Consider the following hypothetical company, Benefast Partners, which provides a specific market niche HRIS product: benefits administration software. Its challenge: Provide comprehensive benefits administration software that meets the needs of a growing and complex benefits marketplace. According to Davis Hunter, a former employee of Benefast, Benefast Partners (name changed to protect confidentiality) was only doing defined benefit pension plans for large employers (20,000+ employees). When you focus your business opportunities on Fortune 100 companies, it limits your potential for growth to small and mid sized markets. Given that there is competition in the market for small, medium, and large clients, there was no real way to expand. We were, however, doing 401(k) retirement plan administration both on our proprietary system, designed and marketed for large employers, and on a purchased platform for smaller companies. We had interest from existing 401(k) clients to take on administration of their defined benefit plans, and we felt we had lost 401(k) business in the past because we didn’t offer total retirement outsourcing, just 401(k). It wasn’t possible to charge small employers the kinds of fees necessary to implement their plans on our proprietary system, so our efforts centered on what could be done with the purchased system used for small to mid sized 401(k) plans. We quickly determined that the purchased system’s defined benefits platform wasn’t sophisticated enough from a calculation standpoint to handle most of the complexity of defined benefit plans, so we decided to use a combination of the purchased system with the calculation engine component for the proprietary system.
We had a lot of needs analysis conversations with our colleagues in another office who were running the project. Given the multiple platforms involved, processing time was a huge concern. We decided to segment the market and serve only those customers who met a fairly stringent set of requirements. Basically, we built a system to serve clients whose plans were easy to administer. In other words:
So, based on this segmentation, we launched our new product with one of our parent companies (a bank). By the time we had signed our third client, we had already begun to move toward a fairly complex multiplan environment. Our fourth and fifth clients were even more complex. We were over budget and off schedule on everything, and then we started trying to figure out how to do coordination of benefits. We built a system for plans that were easy to administer—but plans that are easy to administer are few and far between in the marketplace, and those that exist aren’t typically managed by organizations shopping for benefits vendors.
Case Study Questions