Developers and Other Clients

We work for quite a number of different clients, but their projects are to a degree, very similar. We do projects of that type because we have experience and expertise in doing them. They are familiar to us. Because of that similarity, we tend to look at all of our clients as being similar as well. It is a simple thing, but perhaps not a wise thing, for us to make that assumption. Our unconscious thinking being that if the projects are similar, the clients must be similar.

It is a simple assumption, and under most circumstances, does not create problems. Similar facilities require similar engineering, after all. The degree of detail and documentation may be different, but a certain body of engineering work is necessary to allow the facility to be built. And so we persist in our naive perception of our clients.

But in fact our clients are very different. To the extent that we recognize differences, we personalize them. Both they and we are human beings, with the likes, dislikes, biases and prejudices that are common to that condition. As a result, we easily see differentiation among our clients based on their differences as people, rather than on their differences as organizations. But there are profound differences among our clients based on the type of organization that they represent. Too often we are blind or indifferent to those differences. And those differences can have a material affect, on our business, as well as on our ability to successfully execute projects.

The type of projects that we do require substantial financial commitments on the part of the client. As a result of this simple fact, our clients tend to be large publicly owned corporations. Those corporations usually have mature organizations with well developed procedures and protocols for handling the complex financial, legal and organizational issues involved in building, and more importantly operating, complex and costly facilities. To an extent, we are not even explicitly aware that these procedures and protocols exist. It is simply the environment that exists in which we do projects. It is like asking the fish about the water, and having the fish answer, "What water?"

But there are other types of client out there, and for which we work. One of these other types is what I call, the developer. Developer organizations are often just a few individuals, sometimes a single individual. Their business plan usually revolves around recognizing a business opportunity, determining the facility necessary to capture that opportunity, raising the money to build the facility and then building it. Once built and operating, it is sold to a larger organization, with the developer on to the next opportunity.

Since it is our desire to be a successful business, as well as a successful project driven engineering company, we must take into account the different imperatives that drive the developer client organization as opposed to the large corporate client organization. The first step is to recognize that we provide a different value to the developer than we do to the corporate client.

In the case of the corporate client, we provide the spectrum of resources necessary to accomplish the desired result. The mature organization of the client knows what it wants to do, how to do it and the constraints within which it will be done. That client simply needs some organization to provide those resources in an efficient and cost effective manner. The developer organization is looking for something different. They are looking for the knowledge of what needs to be done. Crudely put, the corporate client is looking for muscle, while the developer is looking for brains.

But here is the trap for us as a business. The scale of work done by the corporate client, as well as the dynamics of that organization, require that large and sophisticated outside organizations actually accomplish the work necessary to execute the project. Not only must the project be built and put into revenue generating service, but the client organization itself has a commitment to operating that project facility into the future. The operation of that asset and similar assets creates potential liability with many stakeholders. Thus the need to proceed on projects in an orderly and measured manner according to the procedures and protocols of the corporation. Thus an organization like ForeRunner employs people engaged in executing those projects for their clients in the manner expected by those clients.

In contrast, the need of a developer is for the basic design and to just get it done. Often the need for that basic design is driven by the financial organization providing funds to the developer. Professionally done high level drawings are as much a part of the business plan presented to potential financial partners as is the pro forma. Once a workable design is in place, many developers will become a DIY (Do It Yourself). Given that the goal of the developer organization is to create an asset that can then be sold, project execution is driven by expediency and short term considerations.

An interesting metaphor for the difference between developer client and corporate client might be that of auto racing. Working for the corporate client might be viewed as being in a car rally. Performance is measured by hitting all the milestones at the correct speed and time. Working for a developer client might be viewed as a drag race. Getting from start to finish is the sole criterion. The car may well be throwing parts all over the track and on fire, but crossing the finish line in the shortest time is the only thing that counts.

Thus working for developers can be a difficult game for engineering companies. Engineering companies often give away their ideas, or sell them cheaply. The idea being that they will capture the client with their ideas, but will then be able to sell the manhours necessary to execute the ideas. This strategy is a real loser for the engineering company in working with a developer. The developer is looking for the ideas, and if they can get them for free, so much the better.