The Solution Development Journey

The story of moving a project from a requirement, through discovery, understanding, documentation, development, and delivery

Starting from a requirement

While most projects start with written requirements, those requirements can vary wildly — the client often recognises they have a problem, but has no idea how to solve it. Conversely, sometimes the client has a solution in mind and is looking for confirmation. Somewhere in the middle, we find clients with a solution already in mind, but with a relatively narrow region of knowledge to draw their solution from. As the old saying goes; “you don’t know what you don’t know”.

The importance of listening

Perhaps the most important task when setting out on the solution design and development journey is to properly understand the problem. You must understand the issues faced by the client — why they are issues, what impact they have — the human story.

The end goal of any sort of solution is to solve a set of problems without causing more. Given your own relatively narrow knowledge of the client’s industry, it immediately becomes important to set up a feedback loop. Initial supposition and presumption must be tested.

Questioning your involvement

While exploring a problem it’s important to continually refactor your reason for being involved. Is the client asking for something that already exists as a “commercial off-the-shelf” product, but they don’t know about it? Does the cost of configuring or extending such a solution outweigh the cost of developing something bespoke? Does the client understand the long term implications of developing bespoke solutions?

Turning understanding into vision

Once requirements have been gathered it’s tempting as an engineer to start thinking about the nuts and bolts of a robust solution. It’s a mistake. While engineers are good at building things, and designers are good at making things useable, there is a middle ground where a designer knows what is possible, and also appreciates what the client might need. Their ideas must stay within the bounds of what is possible while imagining a solution that doesn’t exist.

It’s all about wearing hats.

You need to view a potential solution from the perspective of each actor that uses it. What do they expect to see? What do they need to do? What causes them problems? What is of no concern to them?

There is often a level of compromise involved in early design work — communicating to the client that while there may be several ways to approach a solution, each might have implications in terms of useability, extensibility, scalability, and so on.

It’s important to be transparent — to explain that while one solution might look good now, it will experience myriad problems in the future, whereas a solution that isn’t as immediately appealing might have many advantages later.

Communicating the vision

The conceptual features of new solutions are best illustrated through the use of “user stories”. Rather than endlessly listing functional features couched in technical or product-specific terminology, it’s better to tell the story of each actor in terms of the challenges they face, and how the solution solves them.

Wireframes typically only work for engineers. How many people can look at an architectural plan for a house, and envision the completed structure? If presenting to end-users, it’s far more important to simulate real-world interfaces, rather than present schematics.

Experience has taught me that a picture paints a thousand words — and a moving picture an order of magnitude more.

Documenting the vision

One of the most common billable outputs of a project is documentation — and yet nobody likes either writing or reading dry, technical documentation. It’s often boring, difficult to understand, and a hangover from the Waterfall development programmes that made the likes of IBM rich before they delivered anything of consequence.

As recently as twenty years ago solutions were more often than not presented as functional requirements, functional specifications, technical specifications, and test plans — with innumerable attachments describing resource usage, licensing, contracts, and who knows what else. Documents that had to be re-written, re-published, re-read, and re-approved throughout solution development.

The emergence of “agile” development practices has encouraged minimal documentation — often reduced to “high level” design documentation that grants freedom to designers and developers to interpret requirements without re-entering an endless formally documented feedback loop.

Building the vision

While agile development practices have become very much the “norm” in recent years, it still pays to start projects slowly — to establish a common direction and to allow all parties involved in design and development to understand the bigger picture.

Early decisions are made to solve classes of problem rather than specific situations.

Planning for the future requires that you have anticipated the future — an easy idea to describe on paper, but a difficult objective to achieve in reality. Ideas will evolve. Plans will change.

Solutions are often built by a team with disparate skills. User interface design and development, web service development, database design, system architecture. As the saying goes — “it takes a village”.

Depending on the size of a solution, there may not be a clear separation of concerns — and while some projects may start small and stay small, some grow. It all comes back to planning; understanding that an area may require more development effort, and therefore more bodies. As a project grows, entrusting too many roles to too few individuals generates increasing risk.

Delivering the vision

Following the delivery of a solution, and its exposure to the end-user community, there are some simple methods of ensuring success.

Involve key users throughout the design and development of the solution. Their opinions count. Make them heard, and base decisions on their experience and advice. They will become your “champions” when the solution rolls out to the wider community — the first point of call for end-users to learn from and ask questions of.

Release new builds to small groups. Let them know that they have privileged access to the future. Invest them in the project — listen to them, take heed of their feedback and advice. They will become your second line of support when wider roll-out occurs.

Learning for the future

Each project you enter will teach innumerable lessons that can be taken away, and help form the basis for the planning, development, and delivery of future projects.

Compromise will be expected.

Changes to funding, features, or timescale will always be connected. Any change to one will affect at least one of the others — and not always in a predictable manner. Changing requirements equals less or longer. Less funding equals less or longer. Less time equals fewer features or more cost — but not all solutions can be accelerated by more bodies. Experience will tell.

Agile development requires trust, and is often assuaged by delivering early, and often. While the early part of solution development may be couched in anxiety, getting aspects of a minimum viable product into the hands of end-users often builds trust far more quickly than any promise.

If a client initiates a conversation around a missing feature that may have been proposed many months before, they are missing the point about agile development. Sprinting is about best efforts, fast deliverables and trust — not about guarantees and consequences.

Experience is a huge advantage. It’s much easier for a client to invest trust if you have delivered similar solutions in the past — if you have solved similar problems for others. Demonstrable experience causes your thoughts, opinions, and advice to be heard.