This has been the case for some time. Programmers who create the kinds of software needed to automate basic business processes use standard, widely understood tools. They write code to run on computers and operating systems that are more or less compatible with each other. The protocols through which the various system components communicate with each other are, for the most part, well established.

In other words, the building blocks exist, they fit together and plenty of people know how to assemble them. Then why isn’t custom software development easy? What can go wrong?

The answer is: the same things that can go wrong in any complicated endeavor involving a great many interrelated variables. Inadequate planning. Scope creep. Failure to anticipate changing needs. Poor prioritization.

He continues: “You can’t expect the client to plan and manage the development process. First of all, they’ve got a business to run so they’re too busy. Second, they don’t have the experience - they don’t know exactly what questions to ask themselves to figure out what they need and how to build it. We have to do the asking, then help them figure out the answers.”

When Steve says, “to figure out what they need and how to build it,” he’s talking about defining the type of project under consideration. Even though every software development project is unique (after all, we’re talking about custom software) most fall into one of a number of categories that are characterized by certain parameters. Defining those parameters is the purpose of the first questions we ask.

This is where we usually start:

The great majority of business software is built for the purpose of automating some previously manual process. And because, at this point, most processes that can be automated already have been, custom software development often involves updating or rewriting a legacy system.

In facing this decision, there are a number of factors to consider. Is the legacy system so inadequate that it would just be easier to start from scratch? Was it written in one of the earlier languages that have been superceded by much more powerful and efficient ones? On the other hand, does the company have in-house staff managing the system who would be unable to work with a language other than the one they’re accustomed to?

Of course, not all projects involve legacy software. In those cases, we start with . . .

In most instances, the reason no manual process for producing a particular output has ever been designed is that it would involve a set of tasks so complex that they could not be executed manually. A typical example might be a very sophisticated, comprehensive report on some type of business activity; without software and digital processing, producing such a report would have been prohibitively labor intensive. Software is what makes the project feasible in the first place. But before you can program the software you must precisely define the desired output, identify the necessary inputs, and establish the logic through which raw data becomes useable information. In other words, you have to invent the process.

Next, you have to consider the environment in which it occurs.

This would seem obvious and often is. Usually neither developer nor client freely selects a platform or operating environment; the platform and operating environment select themselves, along with all the technical considerations, complications and advantages associated with them. Unless you are starting a new business, your software will almost certainly be written for the platform you are currently using. And by the way, the choice of platform goes a long way toward determining the choice of a developer; for instance, most Optimal Process software is written for the PC/Windows platform, using the Microsoft suite of development tools including Visual Basic, Visual Baic Script, SQL Server, etc.

That said, issues can and do arise in the process of system design that lead back to the question, “Should we really be doing it this way?”

For instance, think of a company that allows its salespeople access to its corporate Intranet for a variety of applications or data. In the course of developing a new application, somebody says, “If we let our customers use this they’d love us. Let’s put it on the Internet!” But pretty soon, someone else points out that giving access to customers brings up another set of questions altogether, having to do with everything from security to interface design. The point is, the basic issue of just what you're developing in what environment is not always as obvious as it first appears, and very often turns upon the question of who will be using the system. So . . .

Are they internal or external? Your own back office? Customers or suppliers? What process knowledge do they possess? What other knowledge do they possess? Can you train them? Can you control the state of their knowledge?

Steve Cantor says, “The less knowledge there is in the user, the more there has to be in the system.”

In other words, the user’s knowledge level is one of the main determinants of system complexity. The less they know, the more complex the software has to be, because the software has to make decisions that users cannot make, or cannot be allowed to make.

As you can see, then, system complexity is inversely related to user knowledge – the less the user knows the more the system has to. And that goes double for enterprise systems.

Question 4: “Is it an enterprise system?”

An enterprise system is an interrelated group of sub-systems that supports all of a business’s operations – the whole show. And as every facet of an enterprise is related to every other, all elements of any enterprise software system are also interdependent. Data from one place changes data in other places. System alterations in one area may require alterations in others. For these reasons, enterprise systems can be immensely complicated.

With that in mind, here are Steve Cantor’s two laws of enterprise software: 1.) Once a true enterprise system is fully implemented, the business is utterly dependent on that system; 2.) Enterprise systems are never fully implemented.

Point #1 means that as you design the software, you are actually designing your business processes. The software’s structure, logic and workflows constitute what Steve refers to as the “pathways” your people follow as they go about their operational tasks. And configuring those pathways, with all their turns, stop signs and intersections, is not only a complex but an ongoing task.

That leads to point #2, which means that the system is never really “finished” in the sense of having reached some final and permanent form. Business environments change all the time, and processes and procedures have to change accordingly. So building flexibility into the system is absolutely essential.

What does all this mean in regard to the planning and implementation of enterprise software systems? Mainly this: that the task is just too big to take on all at once. Businesses that try usually fail in the attempt and place their organizations under nearly intolerable stress in the process.

Steve Cantor puts it like this: “If you can plan a complete enterprise system and implement it all at once, then your business is so simple you don’t even need software.”

In other words, no matter how thoroughly you plan, it is impossible to account for all of the variables your system must be able to accommodate now, not to mention the changes it will have to accommodate in the future. And since all elements of the system are related to each other, a planning error in one place probably generates mistakes throughout the design. So if you attempt to build and implement a comprehensive system in one fell swoop, you risk spending months (or years) on development only to wind up with something that constrains your people instead of freeing them to be creative and serve customers.

So is it even possible to build an enterprise software system? Yes – just not all at once. The only way to approach an enterprise project is to break it down into manageable phases. Build it a piece at a time.

Where, then, do you start? That’s the next question.

Any sophisticated system must be implemented in phases, and determining the optimal order of implementation has everything to do with how long it takes, what it costs and how well it works. There are two issues to be considered, the first of which is the business priority. If possible, you would like to address the big issues first - you want to accomplish something right away that really does some good. This may or may not make sense, however, from the programming angle. The nature of the system and of its individual building blocks, as well as other technical or practical considerations, determine to some extent the order of implementation. So you try to stike a balance between cost and efficiency on the one hand, and immediate benefit on the other.

When it comes to custom software, the first week of work is as important as all the succeeding weeks put together. That’s when we ask the big questions and help our client make the decisions that establish the shape of the project. The five questions listed here are not exhaustive, but, as Steve says, “If you can get this first stuff right then you’re about half way home.”