Skip to content

Metrics Services

We've refined our metrics design philosophy to a simple, scalable process to support you in the design and development of your tools and programs. Whether you've identified a new need within an existing project, are setting expectations with a client for a new tool, or simply replacing an old tool with a new one, we can help.

Expect to meet at least three times as we work to understand the problem, define a solution, and develop a prototype. Our role can be minimal or more involved, from simply helping you think through the important details to building and supporting the product over the long term.

Our process can be scaled to fit your needs large or small, supporting projects including:

  1. Building an internal tool
  2. Conducting a data analysis
  3. Creating a map, data visualization or dashboard
  4. Evaluating options for a technology solution
  5. Scoping a tool as a product/service for you practice area
  6. Developing a prototype prior to working with a technology partner
  7. Interfacing with technology partners
  8. Building a client-facing tool as a deliverable

We'll work with you through the process of scoping, product definition, specification, implementation and adaptation. What's described below is optimized for developing a medium- to large-effort tool, but will be similar, though less involved, for lesser engagements.

Scoping

Scoping is all about understanding the situation and exploring the problem. We often start by asking you to describe your vision. If its our first time working on this program, we'd like to know your vision for the program, your conservation targets, etc. If we've already engaged, then we'll focus on your vision for the world in which this solution exists. Understanding your vision helps us know what a successful solution will look like.

If that's too optimistic for you, we can instead focus on the problems you face, decisions you need to make, or jobs to be done. We'll have you list the problems and needs so we can zero in on the key problems, who is involved, and the overall situation.

While you're describing the vision or problem, we'll be listening for three things.

  1. First, the people involved. Who are the users and what are their roles? Who are the stakeholders (those affected by the tool)? What are the users' capabilities? The list of people will be refined to a list of users and persona descriptions that describe their motivations and constraints.

  2. Second, their problems or needs. Which can be addressed? What are people doing instead? How will our solution improve upon the alternatives? Problems will be catalogued and we'll ultimately seek to identify the problem, or set of problems, that our solution will address first.

  3. Finally, context. How will this solution integrate with existing tools or processes? What are the requirements, constraints, and design considerations we must keep in mind?

If we come up with questions you don't have an answer for, its helpful to have an expert (whether a true expert or just another member of the project team) available to get clarity before we move on.

While we're not committing to a particular solution yet, we will want to work with you to identify priority problems to address by asking 'How Might We?'. This question allows us to transform problems into opportunities and get creative about potential solutions.

After this meeting, we'll refine our understanding of what you told us, develop testable hypotheses for people and problems, and craft a research plan. We'll do background research to fill in gaps. We may even interview potential users to confirm our persona hypotheses and problem hypotheses.

Product Definition

Utilizing our research and what you've told us, we'll develop options for solutions and develop a recommendation. We'll return with a Product Definition and, potentially, a prototype - some tangible way for you to understand the recommended solution.

The prototype is the minimum build sufficient to test key hypotheses we've developed. It may not even function at all (e.g., a 'wizard of oz' approach), but will simulate the experience of using the tool. It might be as simple as a drawing, a wireframe, or even a small version of what we'll eventually develop. We find it's better to have something tangible for you to react to so that you are fully aware of the look/feel and limitations of any solution.

Also, we may not be able to solve all of the problems (or meet all of the needs) all at once, if not, we'll pick an 'anchor problem' and start there. We'll keep track of other problems to be solved in future features.

This is your chance to give us direction on the scope and solution. Did we overestimate the users capabilities? Forget a key requirement? It's our job to make sure you fully understand the implications of the proposed solution - who will manage it, what is its expected lifetime, what will it cost, etc. We'll also review roles, timeline, and necessary resources.

Specification

We'll document the specifications for the solution in our template Specifications Document, create our project plan and roadmap, and develop the solution or support you to get the product built with a technology provider. Before working with a technology provider, we may develop a simple prototype that will allow you to test and interact with the product so you can be very clear about what you want and how you want it to work.

Implementation

Implementation - the development and deployment of the solution- is simply iteration. We strongly recommend implementing the smallest workable subset of a solution possible. Don't wait for the perfect build out before putting it in the hands of your users. Also, don't overlook the importance of outreach to and education of both users and stakeholders. We can help you navigate the cycle of building and testing that is central to solution implementation.

Adaptation

Almost every tool requires some revision in the first year. We can provide support for the first year and recommend a structured process for adapting the product as needed after a full year of use. The adaptation process should, of course, be scaled to the size of the tool.

Why have we developed this process?

A common component of the delivery of metrics services is the design of tools. We have developed over the past few years a unique perspective and approach to developing tools to support metrics projects. Our tools can include a technology component (such as a scripting language like R or Python), but many do not. The design and development of tools, whether technological or not, is a unique skillset developed within the Metrics service line over the past few years.

We have built out processes and products to facilitate the efficient development of tools that can be used both internally and externally to improve EI services and internal processes. In addition, some EI staff not explicitly included in the Metrics service line have also been developing skills and experience in overlapping areas (e.g., human-centered design). Our aim is to build EI's capacity for effective tool development by promoting the processes and products we have while incorporating the learning of other EI staff in those products and processes.

We are not pretending to be a tech company when we are not, nor develop a competency in the development of software or hardware. EI will continue to work with technology providers to deliver robust technology solutions.

Instead, this is an effort to describe and promote, internally and externally, a subset of the Metrics service line's skillset that is unique to Metrics service line experts. Tool design is central to this, but it can also include data analytics and visualization as stand-alone services. We also explore the opportunity and requirements to deliver Metrics services outside the typical program design and implementation package to new clients/markets, to existing clients, and to internal initiatives.

The Metrics service line can support an effort as small as designing a new budget template to as large as developing an entire information management system for a large agency. We leverage our skills in consulting, design, development, and deployment created through past internal and external work. We work to improve EI's internal practices, expand our staff's understanding of what is possible, and deliver robust, user-friendly tools to clients. Additionally, we seek to increase the capacity of all EI staff to develop lasting solutions.