Ideas, Problems, Requirements
Concepts in the form of Ideas, Problems, or Requirements… How a project begins will lead to excellence and efficiency, or costly mistakes.

Problem

Sometimes a project begins with a problem.

Rebuild

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?

Project Rescue

Perhaps the problem is an existing project that is stuck in the ditch, so to speak.

For example, 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 ship. 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 your code will float around the same way…

Bandwidth

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.

Blending Value

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 cloud services, associated 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.

Restated

So a problem may be an application to rebuild, a project that is not going well, internal teams which are not able to take on all the work required for some projects, or 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.

The third Concept to consider is a Requirement.