emergnContract image

emergnContract

Build better contracts. Optimize client-customer relationships. Deliver solutions on-time and on-budget.

Traditional IT procurement processes have received considerable criticism in recent years. In this era of cost constraint and limited budgets, organizations demand greater transparency in the development process and earlier delivery results. Lengthy design/development cycles are no longer acceptable, particularly when other supply chains have successfully adopted a just-in-time approach. Organizations also need to inject sufficient flexibility into contracts to accommodate change while maintaining service quality and the original fee structure.

emergn™, working closely with gallenalliance Solicitors, has developed emergnContract™ to address these concerns. emergnContract introduces new models for the contract procurement and negotiation processes based on lean and agile principles to meet project needs.

Why use emergnContract?

  • Faster time-to-market
  • Increase in delivery capacity
  • Quality measures around all parts of the solution
  • Improve underlying software platform from previous releases to cut cost of ownership and maintenance.

EMERGN CONTRACT LIFECYCLE:

Over the duration of a typical contract, a lifecycle naturally occurs that consists of three phases: Learning, Calibration and Delivery. The overall structure of the emergnContract considers these phases so that both parties can meet delivery dates, capacity needs and defined quality metrics.

Phase 1: Learning

The goal of the Learning phase is to understand four major elements:

  1. The value case of the project
  2. The high-level release plan
  3. A prioritized backlog with enough stories to start the project
  4. The technical infrastructure needed to develop quality code

The supplier and the client work together to identify, document, prioritize (according to business value and risk) and communicate a backlog of stories (representing requirements of the envisioned software solution) that can be used to iteratively feed the software development team.

It is important to exit the Learning phase with an agreement between the supplier and client on the minimum set of prioritized stories (and the associated story points) to be delivered by a target end date. At the start of the Learning phase and throughout the project, the client should ensure assignment and availability of a Product Owner who represents the goals, expectations and constraints of all associated business stakeholders.

The prioritized story backlog also should be agreed with the supplier delivery team as it considers the value, risk, complexity and effort required to deliver features. The whole team will conduct a Release Planning exercise to define a high-level iteration- and release-based roadmap identifying the sequence of story themes or high-level feature sets.

The story points to be delivered are only estimated before the learning phase, which will then validate the capacity, quality and time requirements.

Phase 2: Calibration

The Calibration phase is designed to help all parties understand how the delivery system of both the supplier and customer impacts the ability to deliver. The idea is to run a few short (about 2 week) delivery cycles to understand the constraints of the system and determine the teams’ velocity. The purpose is to gain feedback from working solutions to be used with customers and business users and to determine any opportunities for improvement.

This will allow understanding of the overall timelines, relative story sizing, velocity and challenges for delivery.

Phase 3: Delivery

The Delivery phase allows the supplier and customer to get to work. It builds in time-boxed iterations so that Change Control is built into the process and allows users and customers to obtain working solutions to understand how requirements are being met and allow them to improve solutions to meet their customers’ needs.

During this phase, there will be many opportunities to inspect and adapt the delivery mechanism. This approach is designed to continuously improve the ability to meet and exceed the capacity, time and quality demands of the project. It also gives both parties multiple opportunities to examine the overall relationship, maintaining a level of transparency to create true partnerships and opportunities for innovation on both sides.

 

Innovations offered by emergnContract:

  • The contractual commitment is for the amount of the output (fully operational software ready to be deployed) rather than the detail of the output (the actual specifications). This is a departure from traditional fixed-price contracts based on time and materials and opens up a number of innovative pricing models.
  • There is no need for an up-front specification because the contractual commitment is for the amount of output rather than the detail of the output. This greatly reduces the time taken to negotiate and manage the contract.
  • Capacity is measured in terms of fully working software, capable of being deployed, that incorporates features as specified by the customer. It is only when this is delivered that the customer receives real value. Reports, updates and deliverables are no substitute for fully working and tested software.
  • Mechanisms are introduced to prioritize required features. One of the greatest forms of waste—building features that are never or rarely used—is eliminated.
  • Existing vendor relationships and sourcing processes are identified and evaluated so that the implementation of emergnContract is optimized across the organization.
  • Features to be built are only committed to at the start of each iteration. There is no need for cumbersome, resource-intensive contractual change control mechanisms.
  • There is a great emphasis on delivering features fast. Metrics are incorporated into the contract to review productivity and provide information to make improvements in the cycle time from feature concept to delivery.
  • Testing is an integral part of the design/development process, used to incorporate feedback and quality, rather than simply arm the customer with contractual rights and remedies.
  • There is much greater emphasis on the quality of the code built. Metrics determine the code’s accuracy, robustness and ease of maintenance are all built into the contract.
  • The risks and rewards of the project are shared and aligned to the skills, competence and expertise of both parties.
  • The shared approach to the delivery model allows both parties to bring their innovations and experiences to the project, which can be continuously improved as a result of the transparency and feedback built into the contract.