Table of Contents

Executive Summary:  The Vision for Modern Legislative Technology

• The Problem
• The Opportunity
• The Xcential Blueprint

Introduction: Why Rethink Procurement?

• ‍‍Evolving Legislative Landscape
• Pitfalls of Traditional RFPs
• Paradigm Shift

Phase 1: Strategic Planning (before the RFP)

• Internal alignment and stakeholder buy-in

Phase 2:  RFP Blueprint (sections and content)

• Project Overview and Narrative
• Functional Requirements
• Technical and Integration Requirements
• Vendor Capabilities and Experience
• Proposal Submission Requirements and Evaluation Criteria

Beyond the RFP - Successful Partnerships

Conclusion: Building the Future of Legislative Work

Executive Summary:  The Vision for Modern Legislative Technology

The Problem 

Parliaments and legislatures around the globe have a problem with existing systems used to draft and publish both legislation and regulation. Existing systems make it difficult to create or capture value relative to efficiency, precision, and integration.

Implementation of a new system that solves for efficiency, precision, integration or connectedness, and future-proofing comes with another set of problems. These problems are often addressed through a government Request for Proposal (RFP) or Tender (note to reader: we will use these term interchangeably). To get the most from a new system, the RFP/Tender will include a list of requirements and an expected cost.  

These RFPs/Tenders often fail. Between 2020 and 2025, many RFPs/Tenders were issued that did not attract acceptable bids.  There are several reasons:

• High cost of bids. Either vendors cannot deliver requirements within a fixed price bid or the estimated cost on a time and materials basis is unacceptable.
• Low vendor participation. With complexity of requirements, many vendors cannot fulfill enough of the requirements or they believe there is too much risk (especially on fixed price bids.
• Reduced innovation. When an RFP/Tender has an exhaustive list of requirements that are both specialized and specific, there is no room for discovery and innovation. Innovation requires trust and collaboration. Innovation also requires a look at first principle problems. So ironically, the volume of specifics directly removes room for innovation which is part of the value governments are seeking to capture.

The result is unmet needs, time is wasted by valuable government staff, and the organization is disappointed by continuing to work with a legacy system.

The Opportunity

Software and standards designed specifically for legislative and regulatory drafting, management, and publication has advanced considerably in recent years.

These systems provide several advantages to parliaments, regulatory agencies, economic development, and citizens.

Modernization & Future Proofing
Modernization of government technology is happening across parliaments, legislatures, and agencies. These new systems bring integration and interconnection between systems providing efficiencies for users and consolidation of system administration. New systems can be deployed and used on-premises and in the cloud, on the desktop and within the browser. New systems can be updated more easily and managed by government staff. New systems should be future-proof, with a path forward to future updates, integrations, and UX. For example, artificial intelligence (AI) may not be necessary today but your new system should accommodate it in the future.

Standards and Interoperability
Standards in the legislative and regulatory space have advanced. LegalDocML and Akoma Ntoso create precision in drafting and consolidation, they enable the building of modular software systems (instead of monolithic systems) for enhancement and maintenance, and they enable transparency for rule-makers and citizens. Moving to LegalDocML and Akoma Ntoso is a meaningful achievement and creates value.

Automation
Automation is available to create efficiency and precision. New systems can automate the creation of required documents such as lists of amendments. Page and line numbers can be automated. Advanced tracking of changes can automate the application and merging of amendments to bills. Producing versions for publication and printing can be automated. Status reporting can be reported automatically as drafting crosses defined stages. The management of citations and sections, even as they move, can be automated. Automation not only reduces time spent on routine activities, but it reduces the opportunity for error which leads to greater precision.

Integration
Integration is expected in new and modern systems. System management becomes simplified when user roles and permissions are managed through integration, instead of separate user management per software component. Data sharing between systems creates the opportunity for better management and reporting. But most importantly, integrated systems allow for the advancement of individual components in a targeted manner. 

Finally, a new system that is (a) based on LegalDocML and Akoma Ntoso, (b) integration ready, and (c) prioritizes automation and precision will create more transparency and a platform for improved citizen engagement.

Every parliament (with an older system) desires a modern system that delivers on the fundamental charter to support the rule of law through transparency and precision. 

This goal is within reach.

The Xcential Blueprint

Realizing the opportunity above requires great procurement. 

Xcential has seen many RFP/tenders for legislative drafting and publishing systems. Below are some recommendations on constructing your RFP/tender, we hope it is useful.

Introduction: Why Rethink Procurement?

Evolving Legislative Landscape

The demands on legislative and regulatory drafters, publishers, and management are increasing. These demands include: volume of bills and acts, complexity, expectations on government efficiency, and the role of legislative drafting services.

The sheer volume of bills and acts has increased over the past years. While the numbers are expected to go up and down from year to year, the numbers appear to be going up.  

For example in the United Kingdom the number of bills that became law saw a general increase:

• 2020 = 29
• 2021 = 35
• 2022 = 48
• 2023 = 57

Another example is the volume of bills introduced by state legislatures in the United States:

• 2020 = 73,250
• 2021 = 117,188
• 2022 = 75,675
• 2023 = 121,537

Complexity is ever increasing. Our democracies tend to address problems when citizens demand action. Governments put efforts into healthcare, then climate change, then global trade, and then government efficiency. These efforts are related and are never resolved. Each issue is important and integrated to others, so a change to climate change law may affect global trade and perhaps even healthcare. 

We don’t take laws off the books very often, so in each legislative or regulatory session the complexity continues to grow.

Government efficiency has become a prominent issue in the United States. As citizens, we should expect the efficient and effective use of public funds. We should always expect that funds will become less available.

Finally, one area Xcential sees evolving globally is the role of a professional, non-partisan group of drafters. We often refer to this group as a Legislative Counsel. They draft bills and amendments, prepare required documentation, and ensure elected officials can introduce high-quality legislation (independent of policy). Most national and sub-national governments employ a group to serve elected representatives in this way. It is typically optional for elected representatives to use these groups, but their use is becoming more common and the volume is increasing. When you add complexity and efficiency, the strain on these professional drafters is ever increasing.

Governments desire for technology transformation, modernization projects, and especially the desire to demonstrate a use of artificial intelligence, is another meaningful change in the landscape. 

Finally, legaltech is evolving rapidly. This makes it important to position the RFP/tender to capture new ideas from new vendors. Make room for new ideas and new technologies.

Pitfalls of Traditional RFPs

Everyone who invests the time to issue an RFP or Tender hopes and expects it to be successful.

Xcential has recognized some key pitfalls that can lead to poor results:

Overcustomization‍

It is important to create an RFP that covers the legislative and regulatory process in full. It is also important to separate the process required by law from the processes that evolved around systems to get the work done. RFPs/tenders that require customization to solve for individual drafter wants will result in complication and costs that put achievement of a new/modern system in jeopardy.

SaaS software proposes that software can be less expensive (total cost of ownership) if you subscribe to the way that particular SaaS software has been implemented. The users are asked to compromise how they work. Custom software does not ask for this compromise and instead is built to match existing ways of working (at a high cost).

It is common for a seemingly small customization require can lead to disproportionate costs and complications. Customization is required, but be cautious.

Lack of modular thinking

Systems are defined by what connects them. One path to a legislative system is to connect related actions within one large blog of customized code, this appears to solve all your requirements in one big upgrade. But the blog makes it expensive to maintain, locks you into a specific vendor going forward, and reduces your ability to upgrade specific parts of the system. It is better to create a modern, modular system where components are integrated but can be updated or enhanced without disrupting the entire system.

Ask vendors or technologists to relative to future-proofing and the value of components versus a monolithic system. Modern engineering teams will promote Agile as a method for rapid prototyping and the incorporation of user feedback to get to a great system. Learn from this approach and why components create agility and long-lasting systems.

Market realities are often overlooked

Software vendors need to make a profit. Profit is related to risk reduction and economic development. When requiring a fixed bid, expect that risk must be built into price and smaller (often more innovative) software firms will either not bid or build risk into a price. Smaller companies may not survive a fixed bid that is incorrect. The market demands a reasonable risk versus reward calculation in favor of the contractor. And the level of risk will directly affect who bids and who the government has an opportunity to work with.

In 2024, there were several tenders for legislative and regulatory systems that failed. This is because they asked for very complex systems that could not be delivered successfully by vendors.

Focusing on How instead of What

The “what” is the problem. For example, “We need a way for customers to easily see their order status.”

The “how” is the specific technical solution. For example, “We need a mobile application for customers to run an order status report.”

In the above example, the “what” leaves options open for building a web application, a responsive website, SMS updates, or even integration with natural language processing chatbots. By defining the “how” we are asking for proposals that eliminate available options and future innovation. 

Gathering a collection of “how” statements from current users can result in a long list of features without understanding their true necessity or priority. This creates situations where a more elegant and cost-sensitive approach could solve all the “what” statements, but a less ideal solution will be chosen to accommodate “how” statements.

When “how” statements are exhaustive, you can almost guarantee that costs will be high and innovation will be low.

Carefully consider requirements that address legislative rules instead of the way staff is accustomed to working. Expect change management to be challenging, but alignment against “what” instead of expectations of “how” will make change management easier. 

Paradigm Shift

If we want to design for a successful system and a successful procurement, we need to move away from “build it all at once” and to “integrate smartly” or “build modular components in an agile methodology”.

We need to abandon monolithic and highly customized systems to component-based systems that are interconnected and future-proof.  We need to foster innovation and better ways of working, instead of exhaustive lists of specific, user-defined “hows”.

The Xcential blueprint for successful RPFs/Tenders is to (a) build with LegalDocML or Akoma Ntoso to create a component-based system, (b) define requirements based on what is needed, not how it will be implemented, (c) leverage integrations with other systems to improve workflow, management and total cost of ownership, (d) consider the market realities of large and small software vendors, and (d) leave room for innovation, agile, and changing requirements as prototypes and MVPs come online.

Phase 1: Strategic Planning (Before the RFP)

Internal alignment and stakeholder buy-in

Internal alignment within a legislative drafting office, legis counsel, or regulatory agency is strong. It is a part of the cultures of these institutions. In practice, alignment is required to get through procurement. 

Alignment is easy when your message to everyone in the organization is “you’ll get what you ask for and this will be painless.”  Alignment is challenging when your message is “we will get a better system, but we might do our work in a different way.”

No one likes change. But change is why we write software. So we plan for change and we manage change. Change management begins when we first consider the project, how we specify the project, and what expectations we set early.

Who needs to be involved

Before the RFP/Tender is constructed and published, it is important to carefully consider who is contributing to requirements.

Focusing on “what” instead of “how” is not always easy for everyone, we all think differently. Take everyone’s feedback and include what you believe make for good RFP/tender requirements. 

Leadership needs to be involved. Who is leadership? Those who shape the thinking of your organization. Understand what is critical to leadership in terms of major initiatives, budgets, timing, and reportable outcomes. If you can deliver reportable outcomes (positive achievements for their stakeholders) for major initiatives on time and on budget, then you have large objects to construct your project around.

IT or Information Technology needs to be involved early. IT is moving in a direction. That direction might be to control all user access from a central control panel. Another might be to move towards vendor managed software on a sovereign cloud infrastructure. Learn how they deploy today and how they want to deploy in the near future. Talk to individuals who have had large-scale, complex system deployments achieved recently; learn why their projects worked and solicit their advice.

Individuals within your legislative drafting or legislative counsel organization are vital. Talk with people who understand what is done on a daily basis. Managers who are accountable to other departments (like publishing and parliamentarians) can help you understand the requirements and flexibility required to integrate with other functions. 

In the above sections, we focused on the benefits of the overall system, the scope, and how to consider key objectives. We want to ask leadership and IT questions like:

• What does success look like?
• What existing systems could this new system replace, augment, and integrate with?
• What is in and what is out of this RFP?
• Is there an MVP that we can define and accept?

Now we need to ask questions that will highlight functional requirements. These questions should be asked of individual users, managers, and members of your drafting and publishing organizations.

• What are the document journeys?  What are the user “jobs to be done” during each of these journeys?
• How is work allocated, communicated, and reported on?
• What information and documents need to be created, stored, and used during these journeys?
• How is data gathered and used? Ask about inputs, tasks completed, states of documents, and necessary outputs.
• How do you find information you need in various stages of a drafting project? 
• How are mistakes handled? What events tend to be error prone?
• What processes do you feel are inefficient?  What processes seem like they could be automated with technology?
• What are the most time consuming jobs to be done?
• What absolutely has to be included in a new legislative drafting and publishing system?

None of the feedback you get will go directly into your RFP or tender. The skill is to listen closely and learn what you believe makes for good requirements. Be careful to limit expectations on items that we call “nice to haves”, expectations lead to difficult change management and staff being unhappy.

Listening for good requirements can be difficult, so we suggest the following.

Assessing Needs = Pain Not Solutions

Smart folks will want to explain to you what the new solution should be. Let them. But we have to focus on the pain of the existing process. Pain says there is opportunity to improve over the existing system. Maybe you have to work overnight when a bill is introduced, this tells you there is an opportunity for automation to make staff more efficient and happier.

Ask about bottlenecks and inefficiencies. You’ll find some of these occur infrequently. Dig deep because often bottlenecks and inefficiencies that occur regularly may be overlooked; they become part of the normal process.

Desired outcomes are another way to discover pain points. Staff may be asked to do things that are not quite in reach, but believe they should be. Compliance with other departments and legal rules are desired outcomes, so discover if there is any pain here as well. It is critical for change management, that you solve pain when rolling out a new system. 

Future-Proofing

Leadership and IT will be concerned with future-proofing. You should consider this as critical as well.

First, do your own research on legislative document standards. Research LegalDocML, Akoma Ntoso, and LegalRuleML. Understand for yourself, if standards matter or not. Do you agree with the perspective of component-based systems? Will you defend the value of standards?

Cloud versus On-Premises is straightforward. Learn from IT what they prefer and align to the future of your organization. Learn why IT is going this direction.

APIs and integration with other systems will be a hard requirement, no system lives alone. Again it is IT that can provide the right answers on preferred methods. For example, IT may prefer that users are authenticated with a common service and roles should be manageable from a centralized panel. Business process triggers and expected outcomes relative to documents and their format come from other departments and should be reviewed with IT.

Xcential does not recommend including artificial intelligence (AI) and natural language processing (NLP) in your RFP/tender. However, leadership and innovative IT staff may push you in this direction. There are great opportunities with these technologies, like conversational search that make searching for documents much more enjoyable. Our recommendation is to understand who AI could be used in the future and ensure that your new system is able to extend and adopt new services.

Realistic Budgeting and Phased Implementation

Budgeting and phased implementation are items you ask about. But you construct them with the feedback gathered.

Total Cost of Ownership (TCO) means how much does this system cost to operate. It includes purchase price, taxes and fees, installation and setup, configuration, customization, training, financing, and hosting to get the software. TCO also includes licenses, maintenance, support, and head count required with a new system.

Component-ortientation or a modular approach frames a phased approach to implementation. Define what you need to see in a proof of concept before awarding a contract. Define what you need in an MVP which allows staff to complete end-to-end work, before implementing automations and “nice to haves”.

All software vendors can do continuous integration and continuous delivery; this is “how” they deploy solutions. But not all are great and delivery MVPs, because this requires a deep understanding of journeys and needs. Define the MVP yourself (with input from others), it will ensure you are prepared to make decisions about tradeoffs and priorities. It also puts you in control of timelines.

MVP is directly related to the budget. You know the budget. The challenge is creating an RFP/tender that virtually guarantees a successful project on budget.

One budget issue is how you will pay for the project, fixed cost bid or time & materials. Vendor gouging on time & materials is real; but it is not hard to see and correct. The problem with a fixed cost bid is risk. Risk limits global trade and risk limits vendor interest in your project. This is especially true of smaller software vendors who know that one or two bad decisions can be an existential threat. Time and materials contracts create agility, flexibility to adjust requirements and budget, and will solicit innovation from the best vendors.

Phase 2:  RFP Blueprint (sections and content)

After you’ve set your strategic framework and gathered valuable input on what should be included, it is time to draft the RFP or tender.

Below we’ll list some basic components of a good RFP. Most importantly, we’ll provide a vendor perspective on these components.

Then we’ll provide some example requirements that you are free to use for a real RFP for a new legislative drafting and publishing solution. These sections can be combined, reordered, or reframed to match your style, but each has a specific purpose.

Project Overview and Narrative

Executive Summary

Purpose of Executive Summary

Summarize the RFP for the reader with a clear and concise description describing the overall project. This is an opportunity to highlight perspectives and facts that will be considered critical to your evaluation.

As a vendor it is easy to get overly focused on details of features, hosting, pricing, and other important parts of the RFP. Pull them out of the urgent considerations and summarize what is critical to the success of a deployed legislative drafting solution.

We recommend drafting a summary early and then redraft the executive summary as one of your last items. Remember the Executive Summary can be followed by the Purpose which will dive deeper into what is important about the RFP, so consider how these sections read together. But you may also combine Executive Summary, Purpose and other sections to create a larger narrative section.

Example Executive Summary

[ORG_NAME] seeks to identify and appoint a suitable service provider to customize, implement, and maintain (for a period) a legislative drafting and publishing system to be used in the drafting, amending, and processing of bills and other legal instruments in the parliamentary legislative process. [ORG_NAME] seeks a legislative drafting and publishing solution that is built on modern technology and open standards.

Further, to transfer skills to [ORG_NAME] staff to be able to set up, operate, modify, provide support and maintain the legislative drafting and publishing system.

Purpose of the RFP = State What You areTrying to chieve

Purpose of Purpose

Explain in this section “why this RFP exists”. It is to select a vendor to build your solution.  Or at least to narrow options down to three.

You are selecting a vendor to build the solution. So the RFP is meant to find someone you can pay to build your system.

Next we explain what we will look for in both a vendor and a solution. We are telling the vendors that we want great software, but that we also want to work with a great company.

There are great companies who don’t make a good match for a legislative or regulatory solution. Here are some characteristics of a good vendor for this project:

• Mature project management processes and manager(s)
• Have delivered similar systems
• Stable in finances and staffing
• Practice agile and consider both hosting and CI/CD from the start
• Understand amending, precision, and parliamentary processes
• Dedicate themselves to open standards (LegalDocML) and open integration with others

Things to consider positive, when evaluating technical responses to requirements:

• Coverage of most important requirements and ability to provide custom solutions. It is important that the planned solution has the flexibility to be built upon, when desired.
• How much of the software will be configured versus developed by requirement. We want a solution that is “out of the box”, as much as possible. In the legislative and regulatory space, each jurisdiction has unique requirements that will require customization, but we want to minimize customization as much as possible. 
• Integration will be necessary for authentication, workflow, reporting, document storage, hosting services, databases, and more. How does the solution’s components communicate with one another (drafting versus workflow) and how do components communicate with non-solution components (authentication). What APIs, webhooks, endpoints, microservices, and serverless functions are available?
• The cost is a critical component. There are two factors that will drive up your development costs: large consulting corporations and custom development. Both have benefits, which is why they cost extra.

Example Purpose

[ORG_NAME] has chosen this RFP process to identify an industry vendor to build the [ORG_NAME] LEGISLATIVE AND PUBLISHING SOLUTION. By reviewing responses to this, [ORG_NAME] will evaluate vendor characteristics and proposals required to successfully deliver this complicated solution.

Vendor characteristics evaluated will include project management, history of related work, financial stability, technical perspectives, maturity of technical processes, and legislative understanding.

Proposals will be evaluated on requirement availability, custom development required to complete solution, integration options, project management, and total cost of ownership.

This RFP may result in the selection of a vendor; or it may result in the selection of two or three vendors to proceed to a proof of concept. The proof of concept will be designed in communication with the selected vendors.

Organization Overview

Purpose of Organization Overview

In this section, explain what your organization does. Explain how you serve the parliament and how you serve other organizations. Explain the roles and responsibilities of who use the solution. Vendors will want to know the number of users as well.

Example Organization Overview

[ORG_NAME] is responsible for the critical and complex process of drafting bills and other legislative and regulatory instruments. We are a professional and non-political department created to serve a bicameral legislature and draft documents for them at their request. [ORG_NAME] was established in [YEAR].

Primary roles in [ORG_NAME] and users of the new solution include:

• Elected Official or Staff - These users will request drafting projects. They may also review drafts during drafting projects.
• Drafters (10) - These users draft bills, amendments to bills, amendments to amendments, and much more. Drafters manage metadata, versions, lists, sponsors, reviews, comments, and more. They prepare documents for use by parliament and publication.
• Reviewers (50) - These users review drafts and final documents for content, procedural and legal compliance, and format. Their feedback is provided to drafters.
• Publishers - These users will receive output from the solution in expected formats and publish according to jurisdiction procedure.
• Consolidators (3) - These users will take enacted bills (or other documents) and consolidate them into new authoritative versions of law.

Key Goals and Desired Outcomes

Purpose of Key Goals and Desired Outcomes

Describe what success looks like. These are not requirements but outcomes. 

Technical requirements explain the details required to perform jobs to be done in the expected manner. Key Goals and Desired Outcomes provide a vision for what you expect to be true after a successful RFP/Tender and a successful project. 

Example Key Goals and Desired Outcomes

Key goals of this RFP/Tender include:

• Find suitable partners to execute the [ORG_NAME]’s vision for a Legislative Drafting and Publishing Solution
• Find a suitable partner who can execute this project within an acceptable timeframe
• Find a suitable partner who can execute this project within an acceptable budget
• Find a suitable partner who can execute this project with technical expertise and vision
• Find a suitable partner who can execute this project with excellent communication, partnership and innovation skills

Desired outcomes of this project:

• Drafters can create required legislative and regulatory instruments required to support the Parliament and does so according to [ORG_NAME] process requirements
• Publishers can publish legislative and regulatory instruments in a manner that supports existing process and tools, supports expectations of transparency for citizens, and creates efficiency of time and money
• [ORG_NAME] has a modern legislative drafting and publishing solution that is more efficient in time and in total cost of ownership
• [ORG_NAME] has a modern legislative drafting and publishing solution that supports open standards and open programmable interfaces to create immediate and future opportunities for integration and interoperability
• [ORG_NAME] has an IT staff and users that are trained to use the system; and have the materials required to train future users

Scope Summary

Purpose of Scope Summary

Give vendors a high-level vision of the solution. Answer the question, “what is a legislative drafting and publishing system?” 

Scope sets the boundaries for the solution. It includes what will be included and what is not included. Requirements will flush out scope, so in the Scope Summary we are drawing large, bold boundaries. It is often helpful to describe what is out of scope to make those boundaries clear.

Scope is not just the left and right sides of a user journey, but includes specifics about how jobs are done, technical formats, integration, and the like. Consider which boundaries are important and highlight them in the Scope Summary.  For example, the use of Microsoft Word vs XML editors for drafting may be an important boundary that will help vendors know early if they can fulfill your RFP/Tender or not.

Example Scope Summary

[ORG_NAME] will select a partner who can:

• Deliver the [ORG_NAME] legislative drafting and publishing solution that is implemented, configured, and customized to (a) draft legislative and regulatory instruments such as bills, resolutions, and amendments, (b) enact amendments, (c) manage all required meta data, (d) enables reviews and collaboration, (e) print documents in required formats for the parliament, (f) automate processes such as amendment generation, numbering, and document synthesis, (g) process bills, (h) publish legislation and regulation in coordination with parliament publishers, and (i) provide the management of documents as projects.
• Work with [ORG_NAME] staff to configure templates and workflow for use by staff
• Deliver to [ORG_NAME] the required knowledge transfer for [ORG_NAME] staff to operate the system and train new staff to operate the system
• Integrate with existing systems to create efficiency for users and IT staff; [ORG_NAME] broadly uses Microsoft products and integration with these products will be weighed as positive
• Deliver the solution in a secure hosting environment that meets security requirements of [ORG_NAME] 
• Base a system on drafting, publishing, and management of documents in XML and full support of LegalDocML to a component-based system

Timeline and Budget

Purpose of Timeline and Budget

Your future partners are looking a few things:

1. Can we deliver this specific solution with unlimited time and budget? 
2. Can we make a profit on this project?
3. Can we deliver this project on time?

Answers will affect their interest in bidding and should affect how they respond to requirements.

We all want successful projects, which does require a successful partner. We want partners to make a reasonable profit. We want them to be eager to support us post deployment.

In any project the dimensions of success include: work to be done, time to do it, money available to acquire time, and efficiency of time. Give your future partner enough information for them to make good decisions.

Example Time and Budget

[ORG_NAME] expects to complete the RFP/Tender process and select a partner by [DATE]. At [ORG_NAME]’s discretion, this date may be extended for further evaluation of partners or at will.

It is the current expectation of [ORG_NAME] that the full legislative drafting and publishing solution will be in its final state of production (end state) by [DATE].

[ORG_NAME] abides by a legislative calendar. It is our goal to have the new system in place and used for the session that next begins in [MONTH] of [YEAR]. There users must be trained and testing completed (including a full mock session) by [MONTH] of [YEAR].

[ORG_NAME] will evaluate a total cost of ownership over a 5 year period beginning at the awarding of this contract. It is the responsibility of vendors submitting to this RFP/Tender to calculate portions of total cost of ownership for which they are within their control. Factors to be considered include: hosting costs, all required software licenses, software development and configuration costs, support costs, and project management costs.

Vendors may propose blended proposals which include fixed costs along with time and materials. [ORG_NAME] will give preference to proposals that relate fixed costs to requirement delivery.

[ORG_NAME] will evaluate success bids relative to time, money, quality of vendor, quality of solution, and risk. Bids which are not within an acceptable range on both time and money will not be considered. Bids that are not within an acceptable range of money, may be asked to reconsider costs at [ORG_NAME]’s discretion.

Functional Requirements

So far, we have outlined meaningful approaches to setting-up the RFP and [ORG_NAME] expectations. Now we use the priorities and stakeholder feedback to construct quality requirements.

Our requirements will paint the picture of the solution and challenge vendors to provide a way to create our best solution. Your requirements should focus on the what, not the how.

The volume of requirements matters, therefore prioritize core functionality and non-negotiables. 10 requirements will not provide enough specificity for evaluation by either party. 400 requirements may overcomplicate responses and tax the human resources of small, innovative vendors.

Do focus on legislative rules and business processes. Be willing to accept flexibility on business processes. Be specific and informative on legislative rules. Legislative and regulatory processes are similar across most democratic parliamentary systems, but jurisdiction rules are often unique and specialized. Remember that many quality vendors who can build a final solution are not experts in your legislative processes.

Requirement Sections

Your vision was maybe covered in the above sections and you should consider short summaries of sections. Short summaries above requirement sections help vendors who must distribute requirements with their company.

Summaries are a great place to provide Use Cases. Use Cases explain how a user accomplishes a job with a system. Use Cases that include diagrams are great, if complex and available.

We will provide short summaries of the [ORG_NAME] solution for legislative drafting and publishing solution. We will combine important sections like hosting and integration because you should partner with IT on those types of requirements.

Here are some sections we feel are unique to an RFP/Tender for a legislative and drafting solution:

• Drafting
• Amendment Management
• Publication
• Document Automation and Archiving
• Reviews and Collaboration
• Legislative Project Management
• System

Drafting Requirements

Amendment Management

Publishing

Document Automation and Archiving

Reviews and Collaboration

Legislative Project Management (LPM)

Systems

Technical and Integration Requirements

Your IT group and future direction will determine requirements in this section. Xcential will point out meaningful considerations, but does not provide sample requirements.

Open Standards Mandate

A modern legislative drafting and publishing system must be based around LegalDocMl and Akoma Ntoso. This is an immediate and long-term decision that pays benefits in money (component oriented system and no vendor lock-in) and long-term flexibility. 

These standards create interoperability between documents and applications. The main reason to do all editing in XML is because of the value of the metadata, structure, and validation that makes interoperability real.

Migrate away from proprietary document formats when it is practical. Xcential is happy to consult on XML and legislative standards.

Security and Compliance

Give these requirements to IT and they may already have standard answers. Do not compromise on these relative to the end state of the solution.

Expect that not all vendors will match the certifications at the point of RFP/Tender. This is for many reasons, including growing businesses that are high-quality, but have not expanded into your region. It may be because products are customized or build from scratch.

Don’t miss out on smaller, high-quality partners if IT believes they could get through security and compliance requirements.

Scalability and Performance

Give these to IT as scalability and performance should be standardized requirements for applications and UX.

Infrastructure (Cloud vs On-Premises)

Hosting is not complicated. The recommendation on hosting should be driven by your strategic modernization plan. 

If the goal is to move into a secure government cloud, then make that a requirement.

Integration Points (where integration is a must)

Integration is a must, we want all solutions to be interoperable. This connects our systems, which helps us automate mundane tasks and the connection itself creates data hygiene.

Consider authentication, roles and users, backups, document storage, training programs, search, privacy, pushing and getting metadata, pushing and getting documents, updating reporting data across systems. The list can get longer. 

Talk with IT and ask where data comes from and where it goes.

Vendor Capabilities and Experience

The best resources to inform vendor capabilities and experience are:

• Internal Guideline - Your procurement team may have a guide that will help with requirements.
• Past Successful Large System Procurements - Talk with people who were deeply involved in successful, complicated project. You may learn small things and very big things. Learn the pitfalls and the qualities of vendors that match your teams.
• Past RFPs - Read through other RFPs for complicated solutions done to replace functioning systems. Maybe read ones that were tied to successful projects.

Relevant experience

Legislative experience is important. You want a partner that understands legislation and regulation. If you have a solution partner without a great subject matter expert, then you have to provide the subject matter expertise.

Work with vendors who have referencable customers in this space. 

Work with vendors who have deep legislative and regulatory expertise and vendors who are skilled at project management and integration. This might mean finding a team of partners.

Team Expertise

Modern software development is critical. This is a modernization project. Work with teams that use modern architectures and open technologies.

If you are going to use LegalDocML, Akoma Ntoso, or LegalRuleML, vendor experience should contain XML engineers.

Methodology

Two meaningful methodologies to utilize are:

• Agile - Important agile methods are deploy often, rapid prototyping, user stories, acceptance criteria, daily stand-up, two-week sprints, sprint planning, sprint retrospectives, and constant customer feedback.
• CI/CD - Continuous Integration / Continuous Deployment. CI means connect all the systems as you go; this includes integration into final hosting. When this is done, problems shrink instead of grow and development velocity increases. CD means to deploy all the way from development to production on a regular basis. This includes test scripts, merging code, regression testing and user testing. The value is that code it tested in components and there are fewer bugs later.

Training and Support

Start by considering new hire training, not your current staff. If you have a training portal or a handbook, then training for your new system should be designed to find that format from the very start. This will ensure you get the final product desired and training for current staff will be based on new hire training.

Proposal Submission Requirements and Evaluation Criteria

Most procurement guidelines will influence things like submission requirements and evaluation criteria.

Recommendations:

• Clarity - Provide clear and simple instructions. Simplify.
• Pricing Structures - If you have defined structures that limit vendor proposals, then be clear about them. If you do not, then allow vendors to propose pricing structures with their reasoning before making a decision. Do not tell vendors how much money you have in the budget until negotiations.
• Evaluation Rubrics - They are popular and add value. Always have a clause in the RFP that says you may override the rubric with approval from procurement. 
• Demonstrations and Proofs of Concept - Require simple demonstrations with finalists. Ask them to show you something with no preparation (if they are a product vendor). Proof of Concepts are good, but they can often be wasted work. Expect to pay vendors for real proofs of concept and carefully consider what is being proved.
• MVPs - Require a Minimally Viable Product (MVP) to be produced at a reasonable place within your timeline. This should be a version of the final solution that can be used end-to-end to do all the jobs of a legislative drafting and publishing solution. 

Beyond the RFP - Successful Partnerships

Here are some final recommendations for working with vendors. There are traits of companies that can be discovered during these activities:

• Pre-Bid Conferences and Questions - There are restrictions on communication during periods around RFPs/Tenders. So plan communication before or during periods of allowed communication. Better communication and understanding by the vendors, leads to better bids.
• Negotiation and Contract Management - Talk money and contracts openly; this is not a topic to be avoided. Vendors are in business and need clarity to make decisions. If you negotiate hard, expect to give in on features. And understand that bids are guesses, so expect things to change and be a partner in finding the right solution.
• Relationship Management - Business is people. Talk early and often with partners you may have a multi-year relationship with. If a vendor is difficult to communicate with, beware.
• Continuous Improvement - Listen closely to vendors and decide if they care about improving themselves. 

This section was purposefully brief. We've taken enough of your time already and we don't feel like this is a major blocker to successful projects (with more organizations). But if you fail to invest in the partnership with your vendors, failure becomes a real risk.

Conclusion: Building the Future of Legislative Work

A well done RFP or tender is the result of great preparation. Xcential hopes this document was helpful in your preparation.

Deciding to modernize software that is used for the most important tasks in a democracy is meaningful. The Rule of Law is the basis of democracy and a legislative drafting and publishing system is responsible for transparency and change to the law.

This is an important system. 

Focus on open standards, modern technology, reasonable and clear expectations, and best-in-class partners.

Xcential hopes our blueprint was useful. You are welcome to use any of the content without reference.

Xcential has built systems for the U.S. Congress, State of California, and parliaments around the world. We are an active member of the OASIS working group on Akoma Ntoso and our LegisPro product supports these standards.

We are experts on legislative and regulatory systems. Xcential works with fantastic partners to deliver modern systems around the world.

‍