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:
- 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).
- Allows the proper time for both the client and Connamara to explore the features together.
- 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.
- Allows the client team and the Connamara team to get to know each other.
- Provides Connamara the information to give a more precise estimate as to the time and cost to bring the solution to life.
- 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.
CEO
