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 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 might 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 midsized 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 midsized $401($k$)$ plans. We quickly determined that the purchased system$$s defined benefits platform was not 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,

No multiplan clients

No retirement modeling

No coordination of benefits, for example, no combination of $401($k$)$ and defined benefit plans

Limited Web interface

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.$$ After reading the study $,$ answer these questions $.1$ How would you evaluate Benefast Partners$$ strategy? $2.$ What changes $($if any$)$ would you make going forward? $3.$ What methods would you employ to ensure that an HRIS package meets the majority of your clients$$ needs?