Sometimes software development is a lot like an arranged marriage. Multiple unknowns on both sides of the equation, uncertain outcomes, and no courting period. Having built sophisticated and innovative software products and services for more than 30 years I can share some tips on how to make love – not war.


Everything we do is going to be challenged from a multitude of perspectives. I’d like to present a few subjects that explain the complexity involved in being a developer, and what we, as a digital agency, do to tackle these challenges in a structured way that helps ensure optimal outcomes for clients and the development company.


This is the first of a series of subjects. It’s about projects.



All we do is mainly envisioned, designed, developed, and delivered as projects. While projects as objects have been around for a while, they originally only meant the plan to execute something – something you do before you actually do it.


First, a little bit of definition.

A project is typically described as being a temporary activity that has a start and end date. A project is, by definition, supposed to be unique. It brings change. It has unknown elements, and therefore creates risk.


The words emphasized above, describe the perfectly defined project. It exists merely in theory, and thus seldomly shows up in practical life. Well, it does show up in projects where we’ve been part of designing and executing from start. But when we take on a project that is partially implemented, or started a long time ago, then we have an imperfectly defined project.


Some projects are envisioned but never receive a formal start date. Others become ongoing developments without a final date. The latter are really not projects anymore, but actually part of an ongoing operation of a business or an organization.


Very many projects are not really unique, and therefore also have generic solutions to apply. Some projects really are not about change being brought, but rather a reaction to change that has already been brought.


All projects though, no matter if they have any of the previously mentioned features of a project or not, do bring unknown elements that implies risk. The risk affects all participants in a project, and therefore it’s one of the most important to embrace before a project starts.


Hello, We Got a Request for Proposal

As business owners we live by partaking in requests for proposals (RFP). This requires, amongst other important facets, that we clearly understand the scope, budget and project risks.


The scope is a clear part of the unknown elements, and so too is the prospective client. Even if the client comes recommended, or if we come recommended to the client, there’s always an uncertainty around what kind of friction our organizations are going to experience.


Let’s say we just received an RFP for $50,000. It involves taking over the development of an existing web application.


This may be a huge investment for the client, and therefore they will be closely guarding the ongoing results of the project. After all, none of the parties involved want to be cause of the downfall of a client.


But…here’s the catch. The client came with the scope. With the scope comes expectations that are unknown to us. An RFPn seldom brings history and clear expectations on what part the project will take in a bigger picture in the client’s business.


And there’s the big problem. The only thing we really know, is the budget. We don’t know the full scope, we don’t know the client. The client doesn’t know use, and both parties will need to work very hard to maintain a relationship that is built upon a fragile foundation.


What We Do Instead!

We often suggest another approach to projects with new prospective clients. One that brings us closer before exposing us to the risk. We split the project in three phases: Exploration, development, and maintenance. The latter is really not part of a project, since it’s missing the main characteristics of what we call a project.


Please note, that I have intentionally left out the reflection phase of a project. It’s technically part of the project, but it’s not important to the current subject.


Before agreeing to take over an existing application, we conduct a technical review. The budget is limited, and scoped differently depending on the project that is supposed to be developed at a later stage.


The client provides us with all the available, pertinent information, and then we conduct a documentation process that involves making an inventory of existing technology, quality, solutions, application vs. business goals, etc.


The fine point here, is that we do this as a limited project that will eventually lead to the next phase. Our exploration always reveals new facts that the client was previously unaware of.


Once we’ve conducted the technical review, then we are able to produce a proposal that minimizes the risk for both the client, and for us. The result is a project that has a much bigger chance of success – and to actually bring the right value to our new client.


What we bring instead of uncertainty, is clarity. Instead of blown budgets, we can scope the right business needs to be implemented, and at a cost that both parties can agree to.


Next up: Technical Requirements