What this BLOG is about

The first – and to this day I still believe the best - book that I have read about managing software development projects is “The Mythical Man Month” by Fredrick Brooks. I read it shortly after its release in 1975 and I couldn’t put it down. I discovered it to be as much of a page-turner as any novel could be (at least for me).

What I found to be especially thought provoking were Brooks’ examples of how and why software project are different from other types of project work.

For example, one of his key observations was that adding manpower to a late software project makes it later.

Imagine that! If you add people to a late project, it only gets later. What other sorts of projects work that way? I believe that the answer is: none!

Let’s say that you are building a brick wall. If you add brick layers, what do you expect to have happen? Clearly you expect that the schedule will be improved.

The same results can be expected from any sort of construction project. Those results can even be expected from most sorts of engineering projects. But that paradigm doesn’t work with software development projects.

But I knew much of this to be true when I read it in the mid-70’s. By then I had already been working on software development projects for nearly a decade. (I wrote my first computer program in the fall of 1966 – it was a FORTRAN program on punched cards. Most people reading this have never used punched cards nor have they ever programmed in FORTRAN.)

The project that Brooks describes in the book was the development of the OS/360 operating system at IBM. That is a “standard” computer program.

As much as I was impressed by Brooks’ insights, I also believe that there are similar significant differences between “standard” software development projects and “custom” development projects. As significant as Brooks’ book was, he offered no insights on custom software development.

For those who are unaware of the differences, allow me to distinguish between the two types of computer programming projects: standard and custom.

A “standard” program is sometimes called a “shrink-wrapped” program because typically (though not always) you can purchase it in a box containing CDs or DVDs along with some written manuals that is covered by clear plastic shrink-wrapping.

A “standard” program is an identical program sold to multiple customers. Examples would be Microsoft Word, Norton Anti-virus, Adobe Photoshop, etc. Such programs also include the shareware and freeware programs that can be found on the Internet. It also includes game software that runs on a game computer such as an X-Box.

A “custom” program generally builds upon a “standard” program to develop a unique software solution for one single customer. The key word in that definition is “unique”.

The best known examples are Enterprise Resource Planning (ERP) programs. The core of the program is a standard program purchased from one of the companies that create such programs. SAP, PeopleSoft and Oracle are the largest vendors of such programs.

But because each company is unique, these core programs have to be customized for every particular company that purchases one of them. Even companies that seem to be identical to each other in terms of type of business, product line, size, etc. all have unique characteristics which cause their ERP programs to be different. Custom software developers make the necessary changes.

It is surprising how often such ERP customization is necessary. I’ve seen multiple instances where a division of one company was spun-off to form another completely independent company. In each case that newly created company developed its own completely unique ERP system. Most people’s intuition tell them that the new company would try to use a computer system to help run their company that was as close as possible to the one that they had been using in their former company. But the new companies have such unique requirements that they need a new system. In the cases that I’ve seen, the new company even used a different ERP standard solution vendor so even the look-and-feel of their new ERP application was different.

A reasonable question to ask at this point is this: is custom software development the same thing as consulting? The answer is no, or at least not exactly.

There are two differences.

First, a custom software developer provides a complete solution. The term “turnkey” is used to describe what they provide. There are no loose ends with such a custom solution. It performs everything described in the specification that defines it.

Consultants, on the other hand, provide only a portion of the overall completed solution. In some cases they provide only expert advice.

For example, if your software program has bad graphics, you might hire a consultant to improve the graphics in the program. Or, if you need to have the program work for Spanish-speaking users, you may need to bring in a Spanish-speaking consultant to define what has to be changed in the interface and also probably participate in the testing of the program to insure that the error messages and other text are consistent with the requirements of users who speak Spanish. But those are only parts of the overall solution. The custom software development project team would provide the complete solution, not just these portions.

The other role of software consultants is to provide advice on process or others sorts of improvements without necessarily providing the solution that they advise the customer to use. Such advice should include some sort of a financial analysis that would help the customer to determine whether to pursue a proposed plan of action.

It should be noted that after the initial solution is delivered it is not unusual for the original custom software developers to take the role of consultants in order to offer advice on new features to include in the software solution.

The second difference between custom software developers and consultants is that, though there are exceptions, custom software developers most often get paid based on fixed cost estimates. In other words, they only get paid the amount of money agreed upon at the beginning of the project. (If there is a change of scope after the initial agreement is reached, then additional charges should apply – but only then.) On the other hand, consultants are more often paid on a Time-and-Materials (T&M) basis. If they work for ten hours, they get paid for ten hours. If they work an eleventh hour they get paid for that additional hour.

As already mentioned, custom software programs are built on top of some standard software program. (That standard program is sometimes called the solution’s ‘Platform’ though that word may encompass other things including the operating system or even the hardware.) Certainly a unique, custom program could be developed without any standard software products. In the 1980’s, when personal computers first appeared, I worked on a number of projects that required software development from scratch. The only “standard” products that were used were the software development tools, such as the compiler and the operating system itself.

But more than two decades have passed since then. During that time, many software vendors have developed applications that can be used as the basis for a custom application. Those base applications have had large amounts of development and testing invested in them that would be difficult to duplicate. The products that the ERP vendors listed earlier are excellent examples. So, in the 21st century, it rarely makes sense to develop the complete application without basing it on some “standard” product.

Often, in fact, the basic software product can be provided by the same vendor that does the customization. This possibility will be discussed in greater detail later in this book.

The staff of programmers and project managers that does the customization may be either internal or external. I’ve worked in both environments and each has advantages and disadvantages. The problem with depending solely on an internal staff is that it is rarely large enough to support all of the justifiable custom software development projects.

I was once called in to develop a capital equipment tracking program for a large company that had its own large internal software support staff. I asked the manager why he was looking outside of the company for someone to develop this software. Here’s what he told me: “Before contacting you, I went to the manager of our internal software development staff. After I described to him what I needed to have done, he said that he would probably put the development of that application at about 5th place on his top-ten list of internal applications to develop. However he also cautioned me that he never gets below about number three on that list. Changing priorities are always inserting new, higher-priority applications. He suggested that as a practical fact he would never get to my application. So that’s why I’m coming to you.”

Regardless of whether or not the custom software is developed internally or externally, most of the same factors described in this book apply. You still have to describe the requirements of the solution in detail. You have to provide estimates. You still have to support the application. Almost everything is the same.

Custom software is also important in every industry that uses software. Since I wrote my first computer program two-score years ago, I have developed software (or worked on projects with software developers who developed software) in these software languages: machine language (that’s the ‘1’s and ‘0’s that computers understand), assembly language (mnemonic-based machine language) on a number of different computers, Fortran, Algol, Pascal, ‘C’, dBase (the primary PC-based database of the 1980’s), Clipper (a compiled form of dBase), “C++”, Java Script, Visual Basic and probably some other computer languages that are long forgotten. I even recall writing a few lines of code in COBOL.

I’ve also worked on very diverse types of applications: automated production systems, automated test systems, accounting software (including Accounts Payable, Accounts Receivable, General Ledger, etc), inventory management software, electronic purchasing systems, credit card issuance systems, identity card issuance systems and others.

I have noticed common characteristics of managing custom software projects which are independent of these different languages and applications. Those common characteristics make those projects different from standard software development projects.

I believe that the differences between standard and custom software development deserve to be explained much as Brooks explained the differences between software development projects in general and other types of projects.

This book is an attempt to explain those differences (and also hopefully add some insights, or at least observations), on software development projects in general.

My intent is to share these ideas with non-technical as well as technical people. So I will explain technical terms and ideas in a non-technical way (hopefully not boring any technical readers while I do that).

One final point – even though this book is written primarily from the perspective of a project manager, it is not intended to be strictly a description of various project management methodologies such as RUP (Rational Unified Process), SDLC (System Design Life Cycle), PMBOK (Project Management Book of Knowledge), etc. (Project managers generally know what those names mean.) I consider using a project management methodology to be very important and I strongly recommend that any company that is not currently using one, evaluate the ones available, select one and then USE IT!

But, I believe that if I was to focus on methodologies this book would be much longer than necessary and may even have less general usefulness. So instead of focusing on methodologies, I will express my ideas in a way that I believe can be applied to any of these methodologies.