The 8 Key Elements of a Federated Buying Agreement

In the “Who buys? Who pays?” article published earlier in this series, we discussed information technology purchases, and how a central buying agency can represent—or fail to represent—affiliate interests.

As a reminder, we identified three parties involved in these types of arrangements:

1. The Head Office (or central buying agency) – positioned to represent the buying interests of a group of affiliates. The Head-office may also buy to serve their own centralized responsibilities in fundraising, advocacy, finance, administration or programs.
2. The Affiliate (Chapter or Office) – who run locally and execute fundraising, advocacy, finance, administration or programmatic work in their respective geography
3. The Vendor (or vendors) – who provide products or services in support of the head-office, the affiliates or both. These vendors may provide software, technology platforms, operational services, implementation services or ongoing specialty services.

In this article, we’ll examine must haves for the central buying agreement itself. The premise is that when central office buys an information system solution it has many factors to consider. The overall deal has to address not only licensing and server\cloud services but must also consider design, implementation, support, modification, retraining, maintenance and upgrade—and it has to do this while respecting scale differences and various scheduling and operational constraints for all represented affiliates.

How long will your agreement need to last?

Consider, for example, that your constituent management system is a LTR (Long Term Relationship) whereas other systems and technologies may change faster, and services agreements may need to be rebid quite frequently – perhaps annually.

So, let’s start with the core constituent management and transactional system.  A complex, integrated constituent management platform usually handles constituent data, constituent relationships and core transactional processing, including revenue processing. This set of features may provide a functional and practical data and software platform for perhaps 10 to 20 years.  During this period, however, business processes, services paradigms, critical data and technology itself, will change dramatically.  Consider the relatively recent emergence of social networks, mobile computing and Business Intelligence platforms. They have become mainstream more recently than most organizations deployed their current core constituent system.

The good news is that a core constituent (or Master Data) solution has characteristics which prevail largely intact for a long time.  Pick the right one, implement it effectively and you are set for a long time. Whereas, the technology vehicles for effectively reaching the constituents that coexist with this core system, may undergo rapid and fundamental shifts driven by new technologies and new messaging paradigms.

Guiding Principles

But regardless of time-frame, are there guiding principles for what an agreement should do? The good news here is that there are standard, proven practices that can tee up the buying framework.

One way, and arguably the most cohesive approach to long-term purchasing stability, is to organize ‘the buy’ within a set of formal agreement subject areas.  Addressing these areas manages the interests and responsibilities of the central buying office (head-office), the vendor, and the affiliates. This is a prudent collaboration since a viable deal structure requires all three to remain ‘whole’ for the lifetime of a purchasing arrangement.

In addition to addressing needs of the three parties, think of each agreement as requiring three aspects or personalities:

• The spirit of an agreement – the medium for setting enduring, overarching expectations.
• The foundation of an agreement – which captures behavioral rules and roles – usually as a set of Service Levels for performance, and Charters that codify roles and responsibilities.
• The scope of an agreement which comprises scope definitions, deliverables and pricing tables.

All three aspects are necessary to fully represent the interests of the three parties – Head-office, vendor(s) and affiliates.

Primary Agreement Checklist

Below is a checklist of the 8 primary considerations in forming a sustainable agreement. These are the 8 agreement subject areas to focus on first. You might argue that there are others, but this is a rather comprehensive starting point to cover the critical success factors.

Keep in mind that this agreement structure is relevant for a range of selections and choices in each area.  For example, hardware and network agreements can underpin solutions that are deployed in the cloud or on premise. The section can accommodate terms for subscription pricing or for more traditional license and maintenance agreements.  In short, the agreement structure describe below is flexible enough to represent a wide range of configurations (centralized and distributed), terms (subscription Vs license), platform options (on-premise Vs Cloud) and services options (in-house Vs consulting and one-time Vs ongoing). 

Agreements	Considerations	Highlights
Master Agreements	Scope and Governance Roles of parties Overall Terms and Conditions Overarching considerations regarding performance and non-performance	What is the overall scope of the program – overall vision and time-frame covered by the Master Agreement.  Who will govern purchasing or amendment decisions within the program and what are the expectations regarding roles and outcomes for the Head-Office, The Vendor(s) and the Affiliates? This is also the place to define overall terms and conditions and any overarching considerations regarding performance or non-performance by any of the parties.
Hardware and Network	Platforms for implementation, upgrade, live production, training Consider growth and replication	This is the hardware or cloud service that provides the physical and networking platform. Agreement consideration should include environments required for pre-go-live phases – such as sandboxes, conversion, development as well as post go-live staging and training environments.Multiple, flexible environments also allow for easier phasing and roll-out increments.
Project Services	Planning and implementation Monitoring and control – including escalation Phasing	Managing multiple vendors, multiple departmental interests and multiple affiliate over a series of project phases can be complicated. A well-defined set of management roles for a project needs to be defined early and codified by agreement. These are the “good fences” that make for “good neighbors”.A recurrent themes in this, and other areas, will be to define the extent to which services are provided by in-house staff Vs consulting or ongoing services.
Business Design and configuration	Initial design and subsequent redesign Replication and any unique bands (small Vs large Affiliates) Validation, QA and synchronization with training	Ideally, vendors now their products and non-profit sponsors and subject matter experts understand their critical business requirements. A well-structured agreement can respect these roles and prevent design spirals and customization demands that significantly add to both the initial and ongoing cost profile.
Data Conversion	Initial deployment Project feature phasing Affiliate roll-out phasing	In addition to an initial conversion of data from a legacy there may also be two types of phasing: to deploy features and function sin staggered phases to deploy sub-groups of affiliates in waves or phases Each will create challenges that should be contemplated in the data conversion agreement.
Data base management and Code base management	Maintenance: Releases and modifications Replication Customization	This is the software heart of the solution – In a later article we’ll focus just on this and on different models for management and maintenance For now it is enough to understand that there will be a preliminary code base that may be customized. Customization may be made for ALL affiliates or just for subsets with similar needs. Expect business needs to change and that new versions to be released. Standardization and frugal customization usually provides the best long-term model for data and code.
Training and Adoption Readiness	Initial training Retraining and distance learning Adoptions and optimization	Team training and initial user training spring to mind but don’t forget retraining for staff turnover or solution modification.  Who does the training? What is the scope of training? when is it done, how is it delivered, how can it be efficiently reusable and easily adjusted for change? All should be considered. There are also many compelling arguments for formal business change-management as a catalyst for adoption and effective use – agreements are often drafted without these provisions.
Ongoing Services	Support – hardware, software, process support, tech guidance Maintenance and upgrade – custom? Production operations – data exchange Specialty services – Marketing, Data supplementation\enrichment, Data quality	This is one of the areas that requires honest self-assessment. What is HO capable and prepared (staffed) to do?  What is each Affiliate capable and staffed to do? and the corollary; What needs to be outsourced or supplemented?Agreements for Ongoing Services can sometimes be time-bound with an intention and timeline to transition from external (consulting) resources and onto lower cost permanent staff.

For now, the scope of this introductory piece is primarily intended to provide a useful checklist— a set of principle ingredients rather than a complete recipe.

Each of these agreement areas can be further explored. In later blogs we’ll focus on management of the code base and the data sharing environment. Readers are encouraged to guide the subject matter for future articles by identifying areas of interest for further exploration.

from npENGAGE http://ift.tt/1QDyvb7