Projects have to start somewhere. Some Concept will lead to action.
We think in terms of three basic forms a Concept may take.
The second form is a Problem.
Sometimes a project begins with a problem. The problem could be a legacy application that needs to be rebuilt with new technologies. Older applications tend to bring great value to a business, but may also introduce costs that are unnoticed. Does a legacy application bind your enterprise to a business process that is too costly, inflexible, or is slowly fading value out of the industry standard for your product or service? Does current or upcoming technology lend itself to new product or service opportunities? Is there an opportunity to begin now laying the groundwork to secure or enhance future profitability?
Perhaps the problem is an existing project that is stuck in the ditch, so to speak.
Sometimes outsourcing companies use approaches that cause more problems than they solve. Some will reuse code to the point that your agile little fishing boat is delivered in an sluggish, massive, complex oil tanker. Excess code and dependencies will plague the application, making it unstable and difficult, if not impossible to maintain.
Other outsourcing companies will reuse code from previous projects, again introducing brittle, shoe-horned code that may be more costly to own than it is worth. And who wants to see comments in code that clearly are from some other customer and project? Which means yours will float around the same way…
But sometimes, the problem to solve is not because of outsourcing, and not because of internal problems with existing teams. Sometimes it is just bandwidth. Often internal development is extremely slow because the business is organized to support operations, and to adjust existing applications, rather than defending developer time and energy for new development. Developing a new application from the ground up requires a different set of skills, and different mindset, and different current experience than one generally uses in an internal operations development team. Consider the preceding statement carefully, to understand the intended meaning. An internal developer may be perfectly suited to new development, in the right environment, but the requirements of the business may deny him that environment.
New development should come from the blending of some things. First, the new work should benefit from exceptional skill working with, and current knowledge of, new technologies. The project should benefit from experience in bringing applications together from a fresh start, with an understanding of the full stack including hardware, network layers, operating systems, databases, application layers, and all these organized to produce a solution infrastructure. Such an infrastructure may be tightly constrained to a small application, or may be broad in scope, depending on the project. But the application has to run somewhere, and these factors are important to consider.
New development should also benefit from uninterrupted focus on the application, so that the energy and thought of the team can be laser focused on solving this specific problem. Developers need time to get into a stride, so to speak, and to maintain that stride. Developers who keep a business running don’t have that opportunity.
The other side of the blend is the knowledge of the business process that the application is built to serve and support. Our customer knows his business best, and knows what needs to be delivered from a process standpoint, and often from an infrastructure standpoint.
Our job is to bring fresh perspectives on the existence and use of new technologies, to ask questions so that we understand your business and goals, and sometimes help discover ways to improve or add value, simply because we have fresh eyes in terms of your environment.
So a problem may be an application to rebuild, a project that is not going well, or internal teams which are not able to take on all the work required for some projects.
Another scenario begins with a specific problem a business faces, which a technical solution might help to resolve. The technical component may participate in driving out cost, or supporting scalability of the enterprise, as a piece in an overall solution.