News & Insights

The Connamara Client Engagement Philosophy – Part 4

Philosophy 3:

Only accept projects where there is a clear understanding and agreement of the features of the software to be delivered

This seems obvious. However, you might be surprised at how many software projects are started where the developer and the client have very different ideas of what the finished project will be.

As an example let us consider the following feature: “As a user, I can view a display of my data over time”. At this point both the client and the developer are nodding their heads in agreement saying, “Yes, indeed, we are going to display the data”.

In reading the feature there is obviously some kind of time series data that needs to be shown to the user. There are at least three general ways to satisfy this feature. We could show the data in a tabular format. Or, we could show it as a graph of some sort. Or, we could provide both ways to visualize the data. Further, are there any interactions between the user and the data (sorting, filtering)? You might agree that the approaches are equally correct in satisfying the requirement and functionality of the feature. However, each solution is very different in the time, cost, complexity and risk to implement.

What we have learned in 19 years of working with our clients is that one cannot accept any feature at face value. Even the apparently simplest feature can be interpreted in many ways.

To mitigate this potential risk to the project, Connamara routinely recommends that most projects begin with an engagement to document and expand the system features so that a clear agreement is reached with our clients before we start writing any code or tests. By making the requirements gathering a separate project, with costs and timelines, risk is mitigated by:

  1. Ensuring that both Connamara and the Client are fully engaged in the project (the client is paying for this and Connamara has reputational risk to do an excellent job).
  2. Allows the proper time for both the client and Connamara to explore the features together.
  3. Produces documentation (user stories, technical requirements and recommendations, data models, implementation roadmaps) that the client can use for issuing a request for proposal from other development teams.
  4. Allows the client team and the Connamara team to get to know each other.
  5. Provides Connamara the information to give a more precise estimate as to the time and cost to bring the solution to life.
  6. With a more precise estimate of the time and cost of the project, the client can more confidently determine the cost/benefit of proceeding with the project without the obligation to the full implementation project.

Jim Downs


Related Reads

Embracing the Remote Revolution: Our Journey as a Remote-First Company

Labor Day Special: Celebrating a Work Culture That Knows No Boundaries As we gather around the virtual breakroom on this.

25 Business Lessons from 25 Years in Business

We reached out to our team members for timeless lessons learned in 25 years in business.

Unveiling Our Next Chapter: Discover Connamara’s Revamped Website and Brand Identity, Celebrating 25 Years of Excellence 

You may have noticed that we recently changed our look. After months of designing and planning, we’re excited to unveil.

Behind Connamara’s Code: Mike Gatny, Part 2

In Part One of our interview with Mike Gatny, VP of Engineering & Head of Sales Engineering at Connamara, Mike detailed what.

Tips from a Work-From-Home Hipster

I’ve been posting silly GIFs and videos on an internal Slack channel at the beginning of every week for I.

Why Connamara Supports Recovery on Water (ROW)

There is no such thing as a bad time to give back to your community. But with October being Breast.

Why We Chose Our Company Values — and How We Live Them

The term “values” is overused and frequently misused in business today. While values are certainly crucial to any company, too.

Get Your FIX: Why (and How) Connamara Supports QuickFIX

The QuickFIX open source project is an important part of what we do at Connamara, and has been for nearly 20 years.

The Connamara Client Engagement Philosophy – Part 6

Philosophy 5: Decline projects when the client can’t grasp the concept of iterative releases (no big bangs) Some of our.

The Connamara Client Engagement Philosophy – Part 5

Philosophy 4: Identify and explain project risks to the client before accepting a project All software projects entails risk. Be.