Handling Potential Conflicts of Interest

It is important to point out a possible conflict of interest that may come up if a custom software vendor does work for two customers who compete with each other. That conflict of interest can occur if one customer pays the vendor to develop a software solution and then the other customer who competes with the first customer asks for a very similar solution. In that case, is it ethical to provide the same code to the second customer, possibly at a discounted rate, when the first customer paid full price for that code?

This is particularly prevalent in software development because a vendor may be hired specifically they have expertise in a particular industry. In fact many software vendors, the smaller ones in particular, specialize in particular industries. Such vendors are almost bound to run into potential conflicts such as this.

A more complicated problem occurs if the software vendor assisted in developing the specifications for the solution. What happens if the vendor helps one customer devise some ingenious and innovative idea that provides that customer with a competitive advantage? Is the vendor allowed to suggest any aspect of that idea to a competitor of that first customer?

The answer: clearly not.

How do you avoid such conflicts? Some customers may request that the vendor sign a legally binding contract preventing them working with competitors, at least over some well-defined time period. In that case it is not a problem.

But if the vendor is, in fact, presented with this problem, I believe that there is only one solution. That solution is to prevent the same project managers, programmers and engineers from working for both customers.

If you instruct the technical staff to avoid discussing such ideas, you’re putting them into a very difficult and possibly impossible situation. How do you separate generic technical ideas from specific ideas?

So the only answer – separate your technical staff into different groups for each competitor.

Note that this is not necessary if the customers are not competitors. I worked for a company that provided ID card solutions. Some of the ideas that were developed for issuing employee ID cards for a telecommunications company were used for a large bank. Some enhancements paid for the large bank were proposed to the telecommunications company. Both companies benefited and neither company paid for any code development that also helped a competitor.

Who owns the source code?

For the non-technical reader, the “source code” can be one file but much more often multiple computer files containing text from which the binary files (consisting really of just ‘1’s and ‘0’s recognized by the computer) are created. This “text” is really, of course, the computer program itself. It is written following strict rules of syntax based on the particular language selected for developing the program. Though the source code files contain text, and can generally be read with Notepad or other text reader programs, they are not generally simple text files and are typically accessed only through the software development environment.

The binary files created from these program files are what the computer actually executes. Anyone who has the source code and the appropriate software development tools (primarily a compiler) can recreate the binary code that makes up the solution.

In summary, the “source code” provides in a human readable form the intellectual property that the software vendor is providing to the customer.

So the question of “who owns the source code” could be rephrased as “who owns the intellectual property”.

This question is relevant to any discussion of the reusability of custom software code.

Equally clearly this is not an issue with standard software programs. In those cases, the vendor pays for the development of the software so they own the intellectual property and, therefore, they own the source code. (Obviously I am ignoring open source code programs with that statement.)

But in the case of a custom software development project, the issue is a bit more complicated. In such cases the customer is paying for the custom code that is being developed. So shouldn’t they have a right to a copy of that code?

If you buy a custom-designed house directly from an architect, you are surely allowed to have a copy of the blueprints!

In my mind, the answer is “Yes!” The customer does have a right to a copy of the source code. I ran my own consulting company for a number of years and I never hesitated to give any customer who asked a copy of the source code that I developed. (I was only asked once to do so.)

While this is my opinion, other custom software developers have a different view.

It is important to note that there are some inherent dangers and genuine complications in giving this code to the customer.

The first danger is that the customer may make changes to the program, unknown to the vendor, but still expect the vendor to support it.

I personally saw an example of this.

In the early 1980’s, I provided consulting support for a number of small companies. That was back in the computer Dark Ages when personal computers were first becoming generally available. Much of what I provided used a program called dBase III. That program was “interpreted” meaning that it was compiled into ‘1’s and ‘0’s as it ran (during ‘run-time’). There are multiple disadvantages to such programs (including needing to purchase a copy of the dBase program for every workstation and the fact that such programs run much slower). But the biggest disadvantage of such programs, relative to the current discussion, is that the source code is readily available to the user (as long as they know a few basic rules about how to access it).

If they have access to it – then they can change it.

I had a customer call and complain about a problem that they were having with one of the programs that I wrote. I stopped into their office to fix it. I quickly found that someone had modified the source code that I provided! It was those modifications that weren’t working. I found out why they wanted those changes and repaired the program appropriately.

In a large corporate environment, there is a clear and present danger in allowing the customer to make such changes. Fortunately, most customers understand these dangers and don’t have any more desire than the vendor to allow such changes by the customer’s representatives. Moreover this sort of problem tends to be easy to spot (the size of and the date-and-time stamp on the binary files will be different, for example). In addition, I can’t imagine a customer who would argue with a vendor who billed for fixing a problem caused by someone working for the customer who modified the program.

A second potential danger in providing the customer with a copy of the source code is that you are possibly enabling the customer to become a competitor of yours. The customer can potentially take what you wrote and resell it, possibly making small changes as they do so but still using the intellectual property that the vendor created as the basis for what they sold. I believe this danger to be minimal. People interested in such custom software are probably people who compete with the customer who has the original code. The customer is unlikely to wish to enable their competitors.

But this possibility, however unlikely it is, can be handled by contract terms within the contract agreed to between the customer and the vendor.

A third problem is that the source code will generally include reused code that was developed initially for another customer. In that case portions of the source code were paid for by other customers. So if you provide all of the code for the customer, it is likely that you are giving the customer intellectual property that they didn’t pay for.

Once again, there is a solution. It takes a bit more work, but the source code that the customer did not pay for can be provided in a binary form rather than in the original source code form.

A final problem is that the source code can be given to another vendor and that vendor can take over the development and support of the program. Again I consider this to be a relatively small danger. The original vendor is bound to be much more familiar with that source code and should, therefore, be able to be very competitive with anything that any other vendor could provide.

But clearly there are dangers and complications in providing this source code to the customer. That is why many vendors believe that the customer should NOT be given that code.

But there is a legitimate reason for the customer to want a copy of the source code is that there is a dangerous situation: the customer needs to have some reassurance that their program can be modified if the vendor goes out of business.

How do you handle that situation?

There are companies that provide the ability to put the source code into escrow. The source code is hidden until (and unless) the vendor gets out of the business.

There is a cost associated with this. That cost should be built into the quotation provided to the customer.

The biggest danger of such escrow accounts that I have witnessed is that while the initial solution is safely put into escrow, any updates are not necessarily included. It should be the responsibility of the project manager to make sure that all updates are put into escrow if such an account has been established for a particular customer.

Code Reusability in Custom Software Projects

Without doubt the most appealing economic reason to get into the software development business is the extremely low cost of reproducing your product compared to the potential selling price.

An excellent example is the first significant database program for PCs – “dBase”.

In the mid-1980’s, a company called Ashton-Tate sold a version of their database management program called “dBase III-Plus”. The program was so popular that within a short time the company was able to write off all of their development costs. At that time, the manufacturer was receiving something like $325 per copy from dealers.

But because the development costs had been fully depreciated, their cost to produce each copy consisted of the cost of a box, a manual, a few floppy disks (yes, floppy disks) and for every few thousand new users probably a new technical support person. Total cost for producing each copy, probably about $25.

If your cost to produce something is $25 (or so) and you can sell it for $325, you are basically printing money.

Which is what we all want to do. I don’t have access to Microsoft’s costs but they undoubtedly have some software products that are in the same category.

But dBase was a “standard” product, not a custom software solution. Can similar things be done with custom software?

Partially, yes - you can do some of the same things. But it is much more difficult. Furthermore, the key word is “similar”. You can never do exactly the same thing for two different customers.

Probably the best examples showing the problems are the various Enterprise Resource Planning (ERP) systems that have developed. If you are unfamiliar with ERP software packages they basically run the company when they are fully implemented. They do no less than control all of the resources, information, and functions of the business.

The most well-known vendors for such software packages are Oracle, SAP and a few others. Those companies provide “standard packages”. But all of those packages require customization because no two companies work with identical processes and types of information.

What is the cost to customize it?

In nearly every case it is more than the cost of the basic package itself. Here’s a summary from Wikipedia:

“For most mid-sized companies, the cost of the implementation will range from around the list price of the ERP user licenses to up to twice this amount (depending on the level of customization required). Large companies, and especially those with multiple sites or countries, will often spend considerably more on the implementation than the cost of the user licenses -- three to five times more is not uncommon for a multi-site implementation[1].”

Any sort of custom software works in the same way.

However there is a difference in complexity. Existing companies, of necessity, already have functions, data and resources and processes built around those.

A new custom software package performing a completely new function within a company won’t have to be integrated with existing processes. In many cases, there will be fewer changes.

But you should expect that there will be some amount of customization. The reason that the customer is buying a custom software package in the first place is so that they can get something that matches, as closely as possible, the way that the company wishes to operate.

Some managers within software development companies don’t recognize that solutions delivered for different customers should always expect to be different from each other.

It is always a good idea to have managers responsible for developing custom software to have custom software development experience themselves. But that is not always the case.

Some such managers only have experience working on standard software development. That, by definition, does not require customization.

Other managers, surprisingly, have no software development experience.

But all of those managers have their eyes on the ultimate prize: the dBase example given above; reselling something for more than ten times its cost.

Furthermore, the extent to which you are going to develop reusable code is the extent to which you need to do market research on the features that should be included in the basic part of the product. When you are developing the initial database design and other features it is a good idea to have the final goal in mind.

As is the case with any business, it is important to understand the market and the product that you are selling.

Here is a true story example of how not to do it.

I worked for a company that developed systems using plastic cards. One set of applications for plastic cards are loyalty programs (like the airline “frequent flier” programs). If you reward people for using your products and services they will tend to prefer your products and services over those of a competitor that doesn’t offer rewards.

It turns out that even hospitals might have a reason to use such a program. I won’t go into the details except to say that such programs can be effective when dealing with expectant mothers in particular.

One sales person for this company recognized the existence of this market. He suggested a plan for developing such a system.

First, we would deliver a system at cost for one customer.

Second, we would deliver additional, identical systems at 50% of cost to other customers. With little or no development costs for those additional systems, we should make significant profits.

Right?

The problem was that we developed the first system while only talking to that first customer. We never had any discussions with the second customer. Then when we dealt with the second customer, that customer wanted something quite different. The applications were only similar at a high level. In fact, probably only about 60% of the code that we developed for the first customer was reusable in the application developed for the second customer.

That’s not an insignificant percentage. But it was still well below the expectations of the managers of the company where I worked. Simply put, the second project lost money because the cost of developing the application for the second customer far exceeded their expectations. So they lost interest in continuing down that path.

My guess is that if they would have sold the application to a third customer, the percentage of code that could have been reused might have been around 80%. Then it would have been continuously higher for each additional customer as new features were added by each new customer. In the long run it might have been a successful strategy.

The primary problems were that the sales people were not familiar with the specifics of what the customers wanted and that the managers were not familiar with custom software development. The managers were used to selling “boxes” – hardware. That’s not changeable. They didn’t understand that customers purchase custom software precisely because it is changeable.
[1] http://en.wikipedia.org/wiki/Enterprise_resource_planning, referenced on March 26, 2009

Margin Analysis during Quotes

The single most important thing to know before creating a quote is the actual number of hours that will be needed to complete the development and implementation. (You also need to know the cost of anything else that is needed to complete the project for the customer.) I have already discussed all of the various factors to use when finding those hours. Note that any contingencies due to risk should be recognized and included in this initial cost evaluation. If there are risks and associated costs that would be present if they become actual issues, then they should be factored in as costs at the initial cost evaluation.

The project manager has the ultimate responsibility for the accuracy of the estimated cost of the project.

Once you are confident that you know the actual costs of developing the solution, you then need to consider the other factors involved in developing the actual price that you quote the customer.

Let us look at those factors.

First of all, each company should have a business model that they have developed indicating the profit level that they expect from their custom software projects. One such marginal profit level that I worked with at one company is 50%. In other words, when you made an estimate for that company, you took the estimated cost and doubled it and used that value as the estimated price to charge the customer. In the simplest scenario, you simply apply the business model multiplier to your costs and – voila – you have your price quote.

A second factor to consider is whether or not some profit will be made from the sale of equipment (hardware) or other things such as service that would be associated with the use of the custom software. Based on my own personal experience, there are tines when this is important.

One company for which I managed custom software development projects made 90% of its revenue and well over 90% of its profit from equipment and not from software. At that company I worked on some projects where $100,000 software costs could produce $1 million of hardware revenue with profits well in excess of $100,000. In such cases, a good business argument could be made to “give” the software away as sort of a “loss leader” since the company ends up with a net profit. (Hardware profits are also much more reliable than the profits on custom software development projects.)

A third factor is that for custom software, often the amount of revenue received for enhancements can far exceed the initial development cost. I have seen estimates stating that, in many cases, the customer’s cost for the initial software development may be only 10% of the total investment in that software product over the life time of that product.

That’s been my own experience as well. I worked for a few years as a self-employed consultant. I wrote a program for a consulting (head hunter) firm to do their payroll. I charged $2000 for that initial development. (It was a very long time ago.) Over the next four years I billed that customer for more than $50,000 for enhancements to that program. It ended up doing much more than payroll. But in that case the ratio of the initial software development revenue to the final revenue was a bit more than 1:25.

While I don’t believe that it makes sense to give the initial software away, you should still consider the extent to which it can be expected to lead to future revenue due to enhancements.

The reason that the customer bought custom software is to have the software support the way that they run their business. Over time businesses change the way that they run. The extent to which the software that you developed supports their business is the precise extent to which the software will have to be enhanced as the customer’s business changes and, hopefully, grows.

This is a key consideration. Back when I was self-employed, I initially did a lot of things to find new customers. Eventually I found 33 customers for which I did billable work. However after about two years I found that I could keep busy by merely fielding requests from those customers for enhancements to the software that I had developed.

It’s important to remember that because it is custom software, the only vendor that the customer can effectively go to for enhancements is the original developer. Even if the customer has a copy of that source code (a subject that I discuss elsewhere) the original developers are the ones who understand it best. So there can be little doubt that they can do the best job of modifying it. Even if the original quote was competitive, quotes for enhancements won’t be.

The extent to which this should be a factor is dependent on the extent to which the software is used on a day-to-day basis. Things like ERP programs are constantly used and will be undergoing constant enhancements. At the other extreme a program that is used rarely, possibly as infrequently as once a year, and then only affects a small group of individuals probably will have very few, if any, enhancements added.

A final consideration is whether a particular customer has an idea for a software program that other customers might be interested in. This should only be a consideration if the vendor has a good marketing department that can do legitimate research into such issues. But in such cases working with a customer to develop a very useful program would make developing a similar piece of software for other customers much easier. In my experience this is the most problematic consideration. But it deserves discussion.

In summary, when establishing a price for a custom software solution the process should be:

Define the requirements in detail.

1. Develop the best possible cost estimate, factoring in risk and anything else that might affect that cost.
2. Apply the default profit margin.
3. Consider lowering the margin if extra revenue for hardware and service sales is likely.
4. Consider lowering the margin if the software is going to be a key piece of software used constantly by the customer. In that scenario the customer will probably pay much more for enhancements over time.
5. Consider lowering the margin if the software being developed has generic features that might make other customers interested in using something similar. This is the most problematic consideration and should only be done if the software development company really has a good marketing department.

All of the considerations should be well documented. It is good to keep a history of such quotes and use them to help evaluate other quotes that will be made in the future.

Evaluating Risk during Custom Software Development Quotes

Risk is a bigger factor in custom software development than it is in standard software development projects. When developing a standard software product the vendor has determined which features are to be delivered as a part of the standard software program. If, during development, you discover that a particular feature becomes too difficult or expensive to develop, you can often remove if from the feature list that you had originally planned on delivering.

This isn’t true of every feature. There are some core features of standard software development projects which MUST be included if you want any sales at all. For example, if you promised to have the new software run on a particular operating system (maybe a new version of Windows from Microsoft) you can’t renege on that promise and, therefore, you will have to deliver that capability even if it takes quite a bit more time and effort than you originally expected. But many times other features, at least those which do not affect the core competencies of the program, can be removed from the feature list. This is something which has to be determined with the marketing team. There may be some disappointed customers who are expecting a particular feature, but it may not affect sales very much. Often with releases of standard software the release date is almost as important as the features that are included.

There is, very obviously, a limit to how much you can do this.

On the other hand, when developing a custom software project, especially if the customer is an external customer, you have made an explicit promise to deliver everything that is described in the SRS. There are no exceptions.

So how do you factor this into the cost quote? What are the risks?

First, the largest risk associated with custom software development is scope creep – additions to the scope of the project after the specification has been approved and the project estimated. Customers are buying custom software because they can’t get everything they want from any of the standard software packages available. So they expect to be able to customize the software such that it exactly matches their needs.

If you want a satisfied customer – and we all want that – we need to allow some variation to a project as it is installed. It’s effectively impossible to write an SRS in sufficient detail that the customer will be able to completely define the requirements. Also many of the sorts of changes that they will want to make may be trivial to implement.

For example, the customer may decide that they would like to use a slightly different character font for their error messages. That might take only a few minutes to implement. If the SRS, understandably, doesn’t go into the detail of specifying the font for those messages, how should you handle that?

The real problem is that this really is a “slippery slope” issue. If you allow one or two minor changes, the customer will continue to ask for more and more. Some of the changes may seem quite simple to the customer, but many will require serious testing. That testing takes time and costs money.

I worked for one company that was extremely strict about any changes. Even something that took but a few minutes to implement required that the full change order process be used. I never saw a customer who complained about that – but the customers had been “trained” to expect it. So that process works, at least in my own experience.

But as an engineer, I personally thought that it was inefficient. I hate inefficiencies.

To resolve this I recommend that you talk to the customer and get an understanding that some changes – many of them cosmetic - will be needed during implementation. You then add an agreed upon number of hours to the quote to cover those. But you keep track of the hours spent making such changes. If the time set aside for them is exceeded, you get an agreement to pay for more hours.

Alternatively, you can get an agreement from the customer to accept a bill for such changes on a Time and Materials basis after the implementation is completed. Note that all of those changes still need to be documented and tested appropriately. But such a system avoids the administrative costs of formally issuing quotes that might possibly also include numerous individual purchase orders and invoices.

The second factor to consider as a risk when quoting a custom software development project, is to recognize that programmers are optimistic. You should get your hourly quotes directly from them (because you get an implicit commitment when you do that) but I’ve never met a programmer who didn’t think that they couldn’t do something in less time than someone else would take. (I would actually be suspicious of any programmer that didn’t feel that way.) So a multiplier should be applied to the number of hours you are given by a programmer. Different programmers are more realistic (or less optimistic) than other programmers so once you’ve worked with a particular programmer and discovered their level of optimism you can “fine tune” your multiplier a bit. When you have no experience with a particular programmer, a good rule of thumb is to double the number of hours that you’re given.

Only in very rare cases will a programmer overestimate the amount of time required to develop a software program. The only exceptions I’ve seen have been when they find some previously developed code that they can use directly or that only takes minor modifications to use in the new app.

With that in mind, if you have the time to do so and/or if the quote is particularly important, as in a competitive bidding situation, it makes sense to look at the specification and compare it to previous projects that the same development team has worked on before. If there have been similar projects in the past, you can cut the multiplier you used on the hours down a bit because it is likely that they will be able to reuse some of the code.

You should always discuss the estimates with the functional manager of the programmers before formalizing them. Ultimately that manager (as well as the project manager) will be responsible for meeting the quote. The individual programmers are not held as responsible. Nor should they be.

SMOP

"SMOP" is an acronym that I learned about early in my career. It stands for:

"Simply a Matter of Programming".

It highlights one of the major differences between hardware projects and software projects.

In just about any hardware project, a new enhancement or change inevitably involves some sort of extra payment to an outside company. If you are manufacturing vacuum cleaners and a customer asks for an exta long power cord, it's more than likely that you will have to purchase that cable from another manufacturer.

In other words, your company will have to write a check to another company.

Software development using an internal staff (which is nearly always the case, especially for custom development) isn't like that. In most cases it only involves having one or more programmers spend a few extra hours writing some more code and one or more testers testing that code. It's just a matter of SMOP - no purchases outside of the company are needed.

If, for example, the customer decides that they would like a new report, and the data needed for that report is already in the database, it might take only a day or so to add that report. Possibly it may take even less.

Customers know this as well as anyone.

What they will often do is actually talk to the individual programmers in order to try to get them to add such features. Such things are particularly common during an installation.

It is up to the Project Manager to make sure that the customer and the Project Manager's own managers don't allow this. Changes require change control. They must be paid for. If you don't do if for every single change then you will lose control.

A problem comes up because there is an administrative cost with documenting a change through the standard change control process. With some minor changes the cost to write up the change request, estimating the cost, having it approved and then updating the speciffication might exceed the cost of making the change itself. That is a solvable problem as well.

Just as companies open puchase blanket orders with vendors in order to allow a large number of smaller purchases without the normal administrative overhead, you can do a similar thing with software changes. You can have the customer agree to have a "blanket change" cost and track costs against that. If the entire budget is not spent, then the customer gets money back at the end of the project. If the "blanket" cost is exceeded then the customer needs to write another check. Even in this case the specific changes need to be tracked. At a minimum the specification for the project must be updated so that it accurately reflects the solution that was delivered.

It is important to emphasize that "bug fixes" don't fall into this category. If the specification for the project says that something must work in a particular way and the customer can demonstrate that it doesn't work that way, then the vendor is obligated to make it work that way at no additional charge.

But an enhancement is something that is different from what the spec says. All of those must be paid for.

The key point is to establish this understanding at the very beginning of the relationship between the vendor and the customer. The software developers need to understand this as well as the customer does.

If this is not understood by everyone, there is a very real possibility that the project will overrun its budget.

Estimating Tasks for the Project Plan

Once the initial project plan is completed with tasks listed, it is time to estimate the time required for the implementation.

First, you should have the people who will performing the various tasks estimate the time required for those tasks. In most cases, because the majority of the tasks involve software development, it will be the programmers who will be making the quotes for the majority of those tasks.

In any case, the best estimate for each task comes from the person who will be performing that task. Clearly they will be best able to evaluate the amount of time required for that task.

But there is another benefit. If you get the estimate for the amount of time to complete the task from the person who will actually perform the task, then you get an implicit commitment from that person to perform the task in that amount of time. On the other hand, if someone else (such as the project manager) estimates the amount of time required for a particular task but that estimate turns out to be too low, the programmer won’t have the same level of commitment. In that case, after all, it is only someone else’s quotation.

In some, probably many cases, you won’t know at the time of the quote who will be performing a particular task. In that case I recommend having the functional manager quote the tasks. When you do that you are at least getting a commitment from the manager of the person who will have to perform the task. If you can’t get either one, then do the best you can. But build some contingency into the schedule.

I recommend that all task estimates should INITIALLY be made as though they had to be performed from scratch, even though in some cases you may be duplicating something that has already been done. Assuming that everything is done from scratch gives you the worst-case scenario. Note that it is still important to factor in risk and make other adjustments. I talk about those later.

The Project Plan should be based on the SRS

Although it is reasonable to develop preliminary plans, the project plan to be used for estimating the cost of the project should be developed only after the Software Requirements Specification has been approved by the customer. Once the spec has been approved, tasks should be created in the project plan.

Each task in the project plan should have a reference back to a specific section of the SRS. If you do this, then it is easy to handle questions about each task as you quote the time required for the implementation.

So what is the best way to do that?

I’ve tried putting paragraph numbers from the SRS into the project plan as references. Unfortunately that only works until you first modify the SRS.

Instead I recommend giving each requirement in the SRS a unique name and then using those names in the project plan. For example, a section of the SRS may say “Aging Report” and the project plan will have a task titled “Aging Report”. It is easier to avoid changing the names of sections in the SRS than it is to avoid changing section numbers.

Ideally some software would allow the SRS and the project plan to be linked together. I haven’t seen any software yet that allows us to do that.

Using Customer Commitments in the Project Plan

One differentiator between standard and custom software development projects is that on custom projects, customers will have commitments that they have to meet in order to achieve the schedule.

On standard software developments, customers are contacted prior to beginning the development in order to get feedback on the features in the software which are important to those customers. But once the development goals are defined in the specification, very little customer involvement will take place, except for the possibility of having the customer do some pre-release “beta” testing of the program.

On custom software development projects, the customer will have more significant involvement in completion of the project. First and foremost, the customer needs to agree on the definition of the project’s features and scope as described in the SRS. But in addition to that, the customer may need to provide the actual servers and/or workstations that will be used in the implementation. Occasionally other specialized equipment must be supplied by the customer. Often, for testing purposes, the customer needs to provide test data

So one key aspect of managing custom software design projects is managing the customer in order to help them recognize and meet these various commitments. The project plan is an important tool to use for this purpose.

The customer should also be included in the project plan as one of the resources. Anywhere within the project plan that you need something from the customer (approval of a specification, delivery of some test data, etc.) make sure that the task is listed and assigned to the customer. In all cases, the customer should be made aware of the commitments that have been assigned to them when the project plan is first approved and whenever it is updated.

For all such customer commitments, you should also add a preliminary task, assigned to the project manager, to remind the customer of upcoming commitments that have been assigned to them. When the project manager reminds the customer, the reminder should be as a gentle reminder, in writing (most likely an email) and the reminder should lay out for the customer the schedule implications if the commitment is not met or if it is delayed.

And, of course, these tasks / commitments should be reviewed whenever there is a project review meeting with the customer. The project manger’s own managers should be aware of all such customer commitments, especially when the customer does not meet any such requirement.

So why do all of this? Is it simply to cover your ass (CYA)?

Admittedly that is a part of it. But much more importantly you must understand the customer’s perspective of the project.

The customer is very interested in meeting the schedule. In fact, as I’ve mentioned already, I believe that in most cases the schedule is the most important single aspect of the project for the customer - especially if the solution is based on a fixed-cost quote. But the customer is depending on the vendor to provide the solution within that schedule. It is easy for them to overlook those things that they need to provide.

I’ve never seen a customer who complained about being reminded of their own commitments. But this is one of the reasons that the vendor should have a good relationship with the customer.

Using the Project Plan for scheduling

If you are making a cost quote, all you really need are the total hours required to implement the solution. The project software program you use should be able to compile a total number of hours for you. But the schedule basically comes for free, or at least takes a minimum of effort. Moreover, including the schedule can have an impact on costs.

But the primary reason for developing a schedule is that the customer will inevitably ask for at least a ballpark quote of how soon the solution can be delivered when he is given the cost estimate. The scheduling part of the project plan will provide that.

It is often difficult to provide a specific schedule commitment when providing a cost estimate (saying, for example, that the solution will be delivered 24 weeks after receipt of the order). The fundamental problem is that it does not make sense to begin work before an order is received. If you don’t know exactly when the order will be received, you don’t know if it will compete with other orders. (While having many orders come in for custom software development is actually a good thing, it does create at least the potential for competition for key resources.) Once the order comes in, you should be able to commit to a specific schedule.

Certainly one factor is the size of the order. If the order is large, consisting of multiple person-years of work, it should be possible to plan for an amount of time to get the necessary resources together and then provide the customer with a schedule commitment at the time that a cost estimate is created.

On smaller project, it is my experience that multiple orders will come in simultaneously (or nearly simultaneously). I’m sure a part of that is due purely to Murphy’s Law, but another part of it involves the way that businesses purchase things like custom software projects. The process that they use is to get an estimate, work to justify it, add it to the company’s budget and then actually order it when the fiscal year begins. I received more orders for new custom software projects during the first month of the calendar year, and certainly during the first month of each quarter, than during the other parts of the year. This is because business fiscal years tend to align with calendar years, and they nearly all align with the beginning of calendar quarters.

Occasionally – especially when responding to an RFP – the customer will tell you when the order will be given to you (if they accept your bid). In that case it is reasonable to provide a commitment for a specific delivery date. Otherwise, I consider such commitments to be very dangerous.

In order to use the project plan for scheduling, you need to put in proper dependencies (e.g. task 2 depends on the completion of task 1). You should also make the schedule dependent on a single initial task (such as receiving the purchase order) which, if changed, will correctly change the entire schedule. It is easier to test “what if” sorts of scenarios when you do that..

Quoting Custom Software Development Projects

Of course the necessary first step of any software project – custom or otherwise – is to define the requirements as described in the previous BLOG entry. Once that is done, a quotation for the work to be performed can be created.

To emphasize the point: if you don’t understand that you really, really need a good definition of the requirements, go back and read the entry titled “Defining Requirements” again.

The Project Plan

Once you have a good definition of the requirements, a detailed project plan should be developed for the purpose of creating the cost and schedule quotations for the custom software development project. I have had particular success using the Microsoft Project program for creating such quotes. No doubt other software packages that can also do the job. Regardless of the software package you use, it should be able to implement the elements listed below.

Project plans have many uses. One of those uses is to track the progress of the project as it is implemented. Particularly in projects containing a number of contingencies – one task depending on the completion of another task – reviewing and monitoring the plan is critical during implementation.

But…

Every project manager that I have ever spoken with agrees that the project plan is MOST important during the initial planning parts of the project.

Dwight Eisenhower once said:

“In preparing for battle I have always found that plans are useless, but planning is indispensable.”

I can’t really compare managing a custom software development project to a ‘battle’, but General Eisenhower makes a good point here which we should all pay attention to.

The Software Requirements Specification (SRS)

The requirements for the project must be defined in detail. A specification is the proper method for providing this definition. Such a specification is sometimes called a “Statement of Work” or a “Functional Specification”. Most often, however, it is called a “Software Requirements Specification" (or SRS) so that is the name that I will use.

As you can tell from the previous discussion, the SRS performs basically the same function as an RFP. In other words, it is a product or a deliverable. As such, it is only reasonable that the customer pay for it. Once they have that specification, they could present it to competing software development firms.

The successful custom software development companies that I worked for were able to get their customers to understand this concept. The unsuccessful companies, on the other hand, were not able to get their customers to understand this paradigm.

Sophisticated customers who are experienced with developing custom applications will have no problem understanding the need for a good definition of the requirements for the project before the work is done.

Less sophisticated customers may not understand how important such a detailed definition for the solution to be delivered. If you are dealing with such a customer my recommendation is that you try to find someone on the customer’s staff that has a technical background. If such a person exists, I would use that person as an ally to talk to the main customer about the need for detailed description.

If you cannot find such an ally, I recommend a face-to-face meeting which includes a presentation of standard project management methodologies – all of which emphasize how important it is to define the requirements.

If the customer is still unconvinced, you should seriously consider dropping the project. I have worked with such customers and they are the ones who continuously ask for and expect without charge “scope creep” enhancements. Such customers are difficult to manage and are difficult to work with profitably.

However, regardless of whether or not you are able to convince your customers to pay for the SRS, that specification should have these characteristics:

1. The SRS should be well organized with numbered sections and/or paragraph numbers. This makes it much easier to go immediately to the proper location in the specification when you are reviewing it with the customer. This also makes it easier to relate the contents of the SRS with the detailed project plan.

2. There should be a new version number assigned to every copy of the SRS that is viewed by the customer, beginning with version 1.0. You should always have the technical staff review the SRS before it is sent to the customer and it makes sense to assign version numbers to these copies as well as to the copy sent to the customer. But the very first version that the customer sees should always be ‘1.0’. If some other number is used the customer will be confused. I recommend that internally reviewed copies of the SRS begin with version numbers such as ‘0.8’ or ‘0.9’.

3. You should use active verbs when writing the spec. You should say, “The system will do ” rather than “ will be done by the system”. This is just a good practice to use when writing a specification.
You should put into the SRS mock-ups of the Graphical User Interface (GUI) screens that will be used when the solution is implemented. Particularly when dealing with unsophisticated customers, this is truly a case where a picture is worth a thousand words.

4. Show as much detail as possible. For example, if the solution is to include reports, you should document the complete specifications for the reports.

To further elaborate on this detail, there are three pieces of information that need to be specified for any report.

First, each report has some selection criteria which is generally entered by the operator. Often that criterion includes a date range. Or it may include a customer code that allows the report to be run for a single customer (or facility, or vendor, or user, etc.) This is where the GUI interface mock-up in the SRS is most valuable.

Second, the specification for the report should document how the data is to be sorted. This is often independent of the selection criteria but on occasion the selection criterion allows the operator to select how the information to be included in the report is to be sorted. For example, in an Aging Report for an Accounts Receivable application you may wish to see all open invoices that are more than 30 days past their billing date. That is the data that is to be selected for inclusion in the report. But once that data is selected, it is normally grouped by customer so that all of the open invoices for each customer are listed together.

Third, the specification for each report should show the detailed information to be shown for each record in the report. Continuing with the example of an Aging Report, the record for each open invoice should include at a minimum the invoice number, billing date and amount. Each group of invoices for a particular customer should show contact information for that customer (generally someone in the Accounts Receivable department who can talk about any open invoices).

Such detail will allow the customer to understand how to use the report and it will also tell the programmer how to develop the code for the report.

Version Control

The latest version of the SRS should always be an accurate description of the current software that has been delivered to the customer. Whenever a modification is made to the software that reflects a functional change that represents a new capability the SRS should be updated to reflect that modification.

Examples:

1. A new report is added
2. A GUI is modified (a screenshot of the new GUI should be included in the modified specification)
3. The software is updated to work on a new version of an operating system.

The version number of the SRS should be modified with each such change. There should be a table within the SRS, preferably towards the front of the document that shows a history of changes. Each row in that table should include: the new version number, the date the change was made, who updated the SRS (it should be the project manager at the time) and a brief description of the change(s).

Some people, particularly attorneys in my own experience, like to have changes tracked within the document. I’m not a fan of doing this. I believe that the document becomes almost unreadable eventually.

Instead, the software vendor should use the same version control software that they are using for the source code itself. The SRS should be included in that database. That version control software will allow the latest version, as well as any of the earlier versions, of the specification to be easily retrieved.

Understand the technology to be used when making a proposal

I will repeat this many times, the most important rule in developing custom software solutions is:

Deliver the least expensive solution that does the job.

If you provide more technology than the customer needs, the customer will end up paying for more than they need. One of the primary ways of reducing cost when developing software solutions is by reusing previously developed code. But that, by definition, means using technologies that have been used before.

But that rule is a little overly simplistic. Technology changes over time. Computer software technologies change much faster than others. Moreover, the customer has reason to expect that what you deliver will not include Windows 3.11 as the operating system when that OS hasn’t been supported by Microsoft for more than a couple of decades.

Another factor can be found within your technical staff. Software developers like change. They would be very unhappy if they couldn’t learn new technologies as they work.

So how do you tell when to switch technologies?

The most important factor is the customer. Most customers are sophisticated enough to understand the advantages of new computer technologies as they become available. Especially if you are responding to an RFP, the customer may very well specify the technology that should be used.

For less sophisticated customers, the software vendor may have to explain the advantages of new technologies. All new technologies have built-in advantages; though developing something new in those technologies will often cost more than developing the solution in an older technology – particularly if a similar solution has already been developed in that older technology. The software vendor (i.e. the project manager) needs to be aware of the trade-offs and be able to explain them to the customer, if the customer does not already know what they are.

Understanding the customer - how well does the customer understand the problem

I think a true story will best illustrate the potential problem here.

When I was a self-employed consultant, I was hired to develop a PC-based Purchase Order tracking system for a small distributor close to my office. I worked with the manager of the group that handled the incoming purchase orders - and only that manager. I asked if I could talk to the people who reported to him and actually processed those purchase orders (in other words, the people who would be the actual users of the program), but he said that they were too busy to help define the requirements for the computer program and that talking to them was unnecessary because he understood the process in sufficient detail to define the requirements

After our discussion, I completed the specification, I reviewed it with the manager who then approved it and I developed the software to match what was written in the specification.

Then it became time to install the application and train the users. I trained the users individually (there were only three of them), but as I did so each of them made this comment: “This isn’t going to help us. It has nothing to do with how we handle purchase orders.”

Based on those comments, I called a meeting with the manager and the users and we found out that – basically – the manager had no idea what the people who reported to him actually did, at least not in any level of detail.

After talking to the actual users, I modified the specification so that it more closely matched the processes that they used. I then provided a quotation to the manager to make the necessary changes to match that spec. The manager acknowledged his mistakes, but he also did not have the authority to get additional funding. Or, more likely, if he asked his own manager for the money, he would have to admit his mistake. So, instead of authorizing me to make those changes, he said that he would get his users to use the program as I developed it. I don’t believe that they ever really used the program.

That is an extreme example, but it illustrates the point.

A more realistic example would be a customer requiring a web-based application, and knowing that they need to encrypt data as it is sent over the Internet, but not knowing whether Secure Socket Layer (SSL) – the most common methodology for encrypting data - is adequate for the customer’s needs. Some customers will understand SSL. Some won’t.

The most important things to learn from the customer are:

1. What is the problem that the computer system is intended to solve

2. What are the current processes (if any) currently used to address that problem.

In some cases the customer will think that they know the answers but don’t. If at all possible, talk to the users who actually implement whatever process is currently being used.

If the customer is ISO-9000 certified, they will have well documented processes. But even then you should review the processes with the users to insure that the processes are accurate. (I know that they are supposed to be accurate because that is what ISO-9000 is supposed to guarantee and the processes should be audited periodically. But some companies are more rigid about following the actual processes than others are. The users who do the work will know.)

Understanding the customer: the level of sophistication

The issue here is whether or not the customer truly understands the need to define in detail the requirements for the software solution ahead of time.

To a great extent, this determination is based on the size and importance of the project. Customers, who want a large custom software project implemented, will assign individuals on their side who have a great deal of understanding and experience in such projects. This may very well include people with advanced degrees in computer science.

For smaller projects, this is not always the case.

Software – especially the custom variety - is still a new enough product that many customers, especially smaller ones, are not very sophisticated about what is needed in order to provide a proper solution. They have a tendency to believe that custom software solutions are not very much different from standard solutions. You buy Microsoft Word if you want to write letters. You buy a different type of standard solution – customized appropriately – if you want to, for example, have an automated manufacturing system.

I once worked with a customer who knew that off-the-shelf software (products such as MS Word) could be purchased for just a few hundred dollars. That customer asked why custom software should cost thousands of dollars.

Most customers aren't that unsophisticated. Hopefully the sales staff will have answered questions such as that before the technical people get in touch with them.

Requests for Proposals (RFPs)

An RFP is issued by the customer. The customer announces that they have written an RFP because they need a new system of some type. For example, one of the states in the United States will announce that they need a new system for issuing driver’s licenses. Included in the announcement will be instructions about how to get a copy of the detailed RFP.

Once that announcement has been made, any vendors potentially interested in responding to the RFP can request a copy.

The RFP is a very detailed description of what the custom solution that the customer wants should include. I have personally read RFPs that run to more than 400 pages. Vendors are allowed to ask questions in writing about the contents of the RFP, which will be answered as long as the administrative rules for submitting questions specified in the RFP are met. Most often the questions asked by one vendor and answered by the customer will be shared with the other vendors. Fundamentally the RFP is intended to be the technical specification for the new solution and generally serves that purpose well.

It should be pointed out that the proposal submitted in response to the RFP must include costs as well as a description of the solution that the customer is to provide.

In most RFPs, much of the text is non-technical. For example, some of it will be a description of the process that vendors are to use when responding to the RFP with a quotation.

The point of this section is to say that if you are responding to an RFP, what follows in the rest of this discussion on defining requirements is really irrelevant. The RFP defines the requirements without the other steps mentioned on this blog.

Having said that, I will mention that if your proposal is accepted, some customers are open to having discussions on modifications to the proposal on the condition that you can show a cost savings or you can propose an addition to the requirements that you can demonstrate will pay for itself in a relatively short period of time. If the customer is open to such a discussion then much of the advice about the definition of requirements becomes relevant again.

Defining Requirements

Any discussion on the subject of managing software development will spend many words emphasizing the importance of defining the requirements for the software before the software is developed. All of them will say that requirement definitiion is the key to successfully managing the development of software projects.

They’re all right. It is the most important aspect of successful software development.

Probably the single most significant area in which custom software development differs from standard software development is in the definition of requirements.

With standard software development, requirements should be defined based on the advice of the marketing group. The marketers should talk to the customers or the potential customers and find out what they are looking for in some software. If the marketing people talk to ten customers and nine of them say that they are more likely to buy the software if it has a particular feature, then you add that feature. On the other hand, if none of the customer wants a feature you don’t add it. If some relatively small, but non-zero, percentage of customers claim that they are more likely to buy your software if it has a particular feature, you do an evaluation of the cost of adding that feature relative to the additional revenue likely to be realized by adding that feature.

This is an obvious process to use. It is amazing that it is not always used.

I worked for a few years for a company that basically allowed the programmers to decide the features to be included in their standard software. The company had a very week marketing department, so the programmers read the software literature and added the newest and greatest bells and whistles they found there, without really any regard as to whether or not any customers really wanted those features. Of course, some of the features they added were things that the customers actually wanted. But the customers had no particular desire for some of the other features that the programmers added. A lot of the cost of developing new features was invested in things that didn't add any sales revenue. Of course, as new features are added the software becomes more complex. The more complex it is, the harder it is to test. Very complex software sometimes requires test cases that are not actually used. The bottom line is that extra features may lower the reliability of the software. If those features do not result in increased revenue, then they should be avoided.

If you invest enough resources into the development, you will add a sufficient number of features to get some software sales. But if those features are not things that your customers are really looking for, then you are probably not going to make much of a profit while you are doing so.

This company sold hardware as well as software and the availability of the standard software improved hardware sales so the company remained profitable (mainly from the sales of their hardware). But they always missed their software profitability goals. This was particularly frustrating because the company’s competitors made more profit on their software than they did on their hardware.

It appears that their competitors actually talked to their customers before investing their resources into a new product.

As important as talking to the customer is when developing a standard software product, it is critical when defining requirements for a custom software solution. The reason that customers purchase a custom software solution is to efficiently and effectively solve a problem that they are experiencing. Therefore it is absolutely necessary for those who are developing that solution to understand the customer’s problem.

We will now discuss the specific steps that should be taken in order to effectively define the requirements of custom software projects.

A project manager must be a good problem solver/Good planner

If you wanted to summarize a good project manager in a single short phrase, I believe that phrase would be: problem solver.

At every stage, projects have problems (or opportunities as some say). The good project managers are those who can keep the project moving along by solving those problems.

Having said that, clearly it is also true that the best projects have fewer problems than the projects which are not-so-good. The best way to minimize the number of problems is by planning for them. So, working hand-in-hand with the ability to solve problems is the ability to plan the project well enough that problems don’t occur in the first place. The two skills are nearly inseparable. I have known successful project managers who are good planners but less skillful at solving problems. I also know of successful project manager who are rotten at planning but can quickly solve every problem that comes around.

The members of the project team generally prefer the better planners, unless they really crave excitement.

Not surprisingly the very best project managers have both skills. They plan well and they can quickly solve the relatively few problems which, inevitably, do surface.

Much of the rest of this book focuses on planning the project (getting the requirements together and documenting them well, planning resources and so on). So in this section of the book, I will focus on problem solving.

One of the keys to good problem solving is simply knowing who knows what. In particular it is important to know who the experts are – particularly who are the experts that you can trust. If you have a database question, who is the best person to ask about databases? If you have a network problem, who is the best person to ask about networks?

These experts don’t necessarily have to be people working on your project, though that would be ideal. However if the expert is not working on your project, you need to understand that the expert’s time is valuable and you should treat it as such. But most people don’t mind offering advice when someone seeks them out as an expert. That sort of advice can help start the problem solving in the right direction and often requires only a few minutes of discussion in order to get some beginning advice. If you are completely unfamiliar with a particular problem that arises, it is good to at least get an initial assessment of whether or not the problem is serious or not.

This is another reason why it is good to have technical project managers. Sometimes they can act as their own problem-solving experts. But, in general, for many reasons, the best plan is to involve the project team in developing solutions to problems.

Some technical problems lend themselves to very obvious solutions. But even those obvious solutions may require extra analysis.

I worked for a while for a company that was investing millions of dollars in a new “standard” software program which replaced an older existing program. The software architects decided to use something called an “object-oriented database”. That database made it easier to develop code. The problem was that the database did not scale well. In other words as the database got larger and larger the performance suffered considerably.

Initially there were no real performance issues. Then when problems with performance started to appear as more data was added to the database, an obvious solution was selected: buy faster and faster hardware. Eventually, every couple of months, they were buying the best and fastest processor and system that they could find and were reconfiguring it and doing their testing on that system. They were fighting a losing battle, of course. Over time, even on their state-of-the-art machines, the new software systems were taking more than a day to perform operations that took the older system less than an hour to perform using much slower hardware. Ultimately the designers chose the only possible alternative – redesign the system with a different type of database (i.e. one that was not object-oriented). Unfortunately the type of database in use was a key part of every software component so the software was delayed by over a year and millions of dollars were lost. (A number of people lost their jobs as well.)

In retrospect, the change of database designs should have been made earlier in the development process. The initial decision to simply continuously select newer and faster software should have been done only after much more analysis which should have begun at least when the problem was first detected. In this specific instance, I would blame the project manager more than I would the software architects for not making the decision to change the design earlier. I wouldn’t necessarily blame the project manager for the initial decision to use an object-oriented database. There probably should have been some questions asked about performance before the design was completed because the technical specification included some performance goals. But once the problem was identified, it was important to come up with the best solution that would not have caused so much time and money to be wasted. Simply buying faster and faster hardware was easy and relatively straightforward, but it was not that “best” solution.

As an aside, in this specific example, the project manager may have to take more of the responsibility than in other technical designs. I’ve already emphasized the need for project managers on technical projects to have a good technical background of their own. But I don’t believe that it is necessary for the project manager to be the best technical person working on the project. To some extent the project manager really does have to depend on his or her technical staff to make the best technical decisions.

But an object-oriented database was a new technology which had not been used before on any project developed at that particular company. As such the use of such a database should have been recognized as a significant risk. Because of that risk the project manager should have initiated some research by the project team, particularly the project team leads, to see what problems may be associated with that new technology. Talking to other customers of that database product is a good first step but there are other ways to do such research. While things have changed quite a bit in the last decade since this situation first arose, the inability of these databases to scale as the amount of data contained in them increases should have been apparent early in that research. The problem could have –and should have – been identified before it was first used as a component in the design.

Custom software projects often don’t have the luxury of performing such research. It costs time and money which can cut directly into the profit margins of the project itself. Because of that it often a good idea to be very cautious when implementing new technologies in custom software projects. Fortunately it is often the case that the customer will make recommendations of the technology that they would like to use. If a new technology is recommended, then the customer implicitly assumes a portion of the risk of using that new technology.

That’s all fine and good. But, if a problem has not been discovered until after development was begun, how should that problem be handled?

In the object-oriented-database example, once it was discovered that the performance of the system was not matching the specifications, the project team should have done an analysis. (In this example they didn’t really analyze the reasons for the bad performance; instead they just figured that faster hardware would solve the problem. Temporarily, at least, it did. But the improvements in hardware performance did not keep pace with the need for faster hardware which was based on the number of objects in the database.)

The analysis should have compared the previous system design with the new design. The comparison should have recognized that the difference was due to a lack of performance in the database. The database, as a single component, could then have been tested under more and more stringent conditions and found not to scale well.

Note that testing such as I suggest doesn’t generally take a great deal of time or effort. System bottlenecks tend to be pretty obvious and generally don’t change much.

How do you solve problems such as this?

There are many methods which people use to solve problems. There are also many different types of problems which can appear on projects. On some projects there may be non-technical problems such as an unresponsive customer. Or you may have two project team members who don’t work well with each other because of some personality conflict.

But the most common problems are technical, so I would prefer to focus the discussion on those.

The best way to solve a technical problem is with the help of the technical team. Some people only like to engage the help of the technical leads on the project. If the problem is relatively minor, that’s probably the best way to handle it. It doesn’t make much sense to involve the entire technical staff in resolving every problem.

But with a larger problem, such as the object-oriented database problem described previously, I much prefer to ask for the ideas of the entire technical team, or at least those individuals involved in the specific area where the problem is occurring. I doubt, for example, that I would get the hardware engineers involved in solving a software problem, though I might even do that under special circumstances.

But when solving a problem, unless the solution is very obvious (such as insufficient test data provided by the customer) the more ideas you have the better. Often the first idea discussed may not provide the solution but it may stimulate another idea which turns out to be the best solution.

Additionally, for the major problems, it may very well have been the project leads whose designs caused the problem in the first place.

If at all possible I also prefer to get the ideas and opinions of how to solve a particular problem in an informal and private environment. As we found out when discussing the personalities of software developers, they tend to be very introverted. Many of them might be unwilling to express their opinion in a large group, particularly if it is critical and may cause some conflict between individuals. But if you talk to them privately and in a non-confrontational manner, you are much more likely to get honest suggestions for solutions.

Hopefully, after talking with the members of the project team, one or more ideas for solutions to the current problem will have been suggested. If none of the ideas seem to be adequate or you have no ideas at all, then the search needs to be extended beyond the members of the project team. In such a case, you could ask for the opinion of others within your company who are working on similar projects or you could hire an outside consultant to help provide possible solutions. (The outside consultant could be expensive and could also, quite possibly, take quite a while to understand the problem well enough to offer possible solutions.)

Once you have a list of possible solutions, you should analyze them for ease (i.e. expense) of implementation and risk. This is another example of an instance where having a project manager with a technical background helps when managing technical projects.

Then discuss them in a meeting with the project team.

The meeting should be open and frank with everyone invited who contributed a possible solution for the problem. Some attempts should be made to quantify the effects on cost and schedule for implementing each of the proposed solution. If any changes to the technical requirements (i.e. the “spec”) would be required, those should be identified as well.

At this point in this discussion, it is important to remember that when a serious problem which needs correction occurs on a project, in nearly every case a compromise of some type must be made with the three key project deliverables: specification, schedule and budget. Often, in fact, more than one of those deliverables will have to be compromised.

Such problems do occur on almost any project. That’s why contingency should be built into the project plan for both schedule and budget (even occasionally for specification). Even when you do that, there are times that the technical problems exceed the planned for contingency.

On a custom software project, I contend that the least important factor is budget. If you can deliver a solution that meets schedule and specification then the customer will probably come back to you for future enhancements. There’s a good chance that you’ll get the money back in the long run. However if you do something to make the customer unhappy with what you’ve delivered, you’ve severely hurt your long-term relationship with that customer.

In the example of the poorly performing, object-oriented database problem that I described earlier.

Clearly the second time through the process you should do some testing.

A good project manager must be a good communicator

The project manager will be working with three different stakeholders: the customer, the development team and his managers. Each group requires nearly constant communication. But each group has a diverse set of interests and priorities as well as different levels of technical knowledge.

Surely it is true that all three groups have an interest in meeting all three of the project goals of specification, schedule and budget. But each group would prioritize those three goals somewhat differently.

If the customer is paying for the solution on a Time and Materials basis, cost will be the highest priority. But in my own experience, most of the time, the customer is offered a fixed cost estimate. In those cases, the customer understandably loses much of their interest in managing the cost. Instead they focus on the technical features (which I call the “spec”) and the schedule. The importance of those two things is relatively equivalent to most customers, but of those two things, I believe the schedule is often the higher priority.

First of all, often the customer representative who you are communicating with is another project manager. That person is responsible for the same things that the vendor’s project manager is responsible for: spec, schedule and budget. Therefore the customer’s own project manager is making commitments to his or her own managers and other stakeholders that are based on the commitments that you are making. The most visible of those commitments is the schedule.

That’s because changes to the schedule will cost the customer money. They may have to get their technical staff to plan for some infrastructure changes in order to implement the solution and they have to make the users of the new solution available for training. Often that means changing the hours that those users can support production with the older system. Sometimes it even means completely shutting down production with the older solution. Such things require notification and planning. Delays cause extra expenses.

So while the customer surely wants the solution to work with all of the agreed upon features, it is often the case that the customer will delay the inclusion of some features, particularly if the missing features are not key features for the application, as long as the solution can begin to be used when scheduled.

The second stakeholder is the technical team. Their main concern is most often meeting the technical specification. Their job is primarily to make it work. Moreover, that’s what they enjoy doing. Budget and schedule – while surely important and the programmers understand that – are secondary to them. They may actually try to provide more than the customer needs or even wants as long as the challenge of providing those features is interesting to them. (By the way, this is one of the reasons that it is good for the project manager to have a technical background. It is easier for a technical project manager to recognize when the programmers are adding things into the development that really aren’t needed. Note that not all features that programmers add are obvious to the user.)

The final stakeholder is the project manager’s management. The technical specs are the least important feature to them, though the managers understand the need to meet the specs. Instead their primary interest in that regard is whether or not the customer will accept the solution. Schedule is slightly more important. A delayed schedule means delaying the movement of the members of the technical staff working on this project over to another project.

But their main concern, in my own experience, is nearly always cost. Which makes complete sense, of course. After all, if you are not making money on your projects you can’t stay in business very long.

So the project manager must effectively communicate with all of these stakeholders, each of which are emphasizing different aspects of the project. But the forms of communication are different.

The overriding and most important document is the SRS. It has to be written in a way that it can be understood by the customer as well as the development team. That is a difficult but achievable task.

Customers also want to have periodic status updates. These must be based on input from the development team. On large projects weekly conference calls are the most effective way of doing this. Individual developers can participate, but as long as the project manager is able to understand the status, their participation is not necessary.

On smaller as well as larger projects, I recommend keeping an issues list. Any issues that the customer raises should be included. Issues raised by others, particularly the development staff, don’t necessarily need to be on the list that is shared with the customer. That is not to imply that you should keep secrets from the customer. Instead it means that some things raised by the development staff may be more technical than the customer has any interest in.

This issues list that you review with the customer should have the following characteristics:

1. An issue number. This allows easy reference to each specific issue.
2. A short name for each issue. This is another way to reference each issue, which is another way to make those issues easier to remember. (The customer may remember what “issue number 24” is, but they are more likely to remember a name like “Long search times”.)
3. The date that the issue was added to the list.
4. The person who raised the issue.
5. A longer description of the issue.
6. The person who is assigned to resolve the issue. Often this is the project manager. If the issue reflects a problem with some portion of the code, the issue may be assigned to the programmer who wrote that section of code.
7. A history of what has happened on this issue. This narrative will be added to over time and can become quite long. If attempts are made to resolve the issue which are unsuccessful, that historical information should be tracked as well. It is best that the person assigned to resolve the issue update this section of the issues list. However the project manager can do it as well.
8. The date that the issue was closed (if it is closed). Note that if the customer is involved, then the customer must agree that the issue has been closed. A date in this column means that the issue has been closed and need not be discussed when reviewing issues.

When communicating with the customer, it is important to do so in ways other than strictly through emails and other written mechanisms. Surely email messages have their place, particularly when exchanging electronic documents. But oral communications help immensely when creating a relationship with a customer.

That relationship is very important.

Communicating with the software development team is more a matter of listening than anything else. You should always remember that you are dealing with a group of people who tend to be very introverted. One-on-one communication often works best.

However you do it, you need to sense frustration, conflict but also be able to follow the progress of the project. If the team is going in non-productive directions (generally when they are trying to implement new state-of-the-art techniques that may be more than the customer needs) you need to be able to understand and step in. It is good to have periodic project status and schedule review meetings (generally weekly), but it is also a good idea to meet with at least the key members of the project team informally more often. I generally try to spend at least five minutes with each key team member every day.

The amount of communication that you have to do with your managers depends on the importance of the project, the stage in the project’s development that you are at and, in some cases, the amount of trouble that the project may be in.

Early in most projects, particularly when you are developing the requirements for the project, your managers may not show much interest. They will have an interest in the schedule and cost of the project, but the technical requirements of custom software projects are of much less interest to them. As you begin the implementation of such projects, however, if the project is important the level of interest of your managers will rise significantly over time.

On very important projects, your management is going to want to be included on project status reviews. They will probably wish to participate in the status reviews done with the customer. Certainly you should expect to update them on project status at least once a week.

If everything on the project is going well, the level of interest of your managers in the project will not exceed such weekly meetings. That is, of course, another reason why early in a project the level of interest of your managers will be relatively minor.

But if the project does start to fall behind on schedule or budget (and less importantly on spec) the level of the managers to whom you will have to report will increase. I’ve always considered it to be somewhat ironic that important projects that are in a bit of trouble require more and more reporting which effectively helps to remove the people who can solve the problems from operating in that role.

A Project Manager should have good technical abilities

It is very important that the Project Manager for custom software development projects have technical experience; i.e. have programming experience. In fact, if possible, that manager should have a good understanding of the particular technology being used in the project.

The project manager should be the person who works with the customer in order to define the requirements of the project. If that person does not understand the technology being used they will not recognize where there are possible tradeoffs.

Allow me to provide an example.

In the early 1980’s, I worked on a project that was a joint venture with another company based in California. The project was to develop an automated system for testing the heads and disks used in computer hard drives.

Some of the specifications for heads and disks include requirements for things like signal-to-noise ratio and something called “peak shift” which could be best measured by expensive instruments purchased from a third-party. Five instruments costing a total of more than $100,000 were required for the complete suite of tests that needed to be performed. However, no two instruments were used at the same time. In addition some time was spent replacing the head or disk being tested with another production unit. This included the time required for the disk to get up to speed and then stopped. The bottom line was that each of these expensive instruments was sitting idle at least 80% of the time.

A more efficient way to utilize those expensive instruments was to share them among multiple “test stands” containing heads and disks. In that way the utilization of the instruments could be increased significantly. When one of the instruments had completed testing on one test stand, it could be switched over to run that same test on one of the other stands. Moreover the instruments could still be utilized while one of the heads or disks had completed testing and was being replaced.

I managed the project to develop something that we called an “Instrument Bay Controller” (or IBC). The other company developed the test stands where the heads and disks were mounted for testing.

One of the issues that came up is which sort of computer-to-computer communications should be used. Two alternatives were considered: RS-232 and Ethernet. (These can be explained in more common terms by comparing them to methods of connecting to the Internet. RS-232 is the method used for dial-up. Ethernet is the method used for high-speed connections.)

Note that this decision was made about 25 years ago. At that time, the hardware for an RS-232 connection cost $75 per connection. An Ethernet board cost $2000 per connection. In other words, connecting two computers together required two boards – one in each of the computers. So the cost of that connection would be $150 using RS-232 but $4000 using Ethernet instead. There are other costs as well. For example, Ethernet cables were considerably more expensive than RS-232 cables, though that cost difference has gone down considerably. Also because Ethernet technology was relatively new at the time, a larger amount of software development was required to implement it.

I knew two things that affected the decision. First all of the messages exchanged between computers were relatively short with a maximum length of 20 characters. I also knew that the disks were spinning at 3600 RPM which meant that any single revolution of the disk took 16.7 milliseconds. Any message between computers that took less than 16.7 milliseconds to transfer would not impact the overall throughput. RS-232 could exchange such short messages within that window of time.

The company that we were partnering with wanted to use Ethernet. I recommended RS-232. We arrived at a compromise where either could be used. When we put the system into production at our company, we used RS-232. Our partner used Ethernet.

Why did the other company decide to use Ethernet?

The decision was made primarily because their entire technical team recommended Ethernet. I personally believe that they made that recommendation precisely because Ethernet was the state-of-the-art. They all lived and worked in Silicon Valley and, as superficial a reason as this might be, they wanted to be able to tell their peers that they were using Ethernet. Certainly Ethernet has technical advantages over RS-232 (just as high-speed Internet connectivity has advantages over dial-up) and those technical advantages were described in detail to the managers at the other company who made the final decision on which technology to use. However because those managers never understood the actual design, then didn’t understand that in this application there was no real advantage. So that lack of technical understanding cost the company many thousands of dollars.

It is worth noting that about two years later we added Ethernet to the IBC because we needed to send the test data to a database server so that the test results could be analyzed in detail. However by then the cost of Ethernet had come down considerably. Also the technical advantages of Ethernet became very relevant: the messages had many more characters in them and the database server was very far away from the location where the testing was done so that RS-232 simply wouldn’t have worked. But we never had to use Ethernet as the communication methodology for communicating between the IBC and the test stands.

Though it is more of an example of a hardware tradeoff than a software tradeoff, I think that it does demonstrate how important it is for the project manager to have a technical background in order to make the best decisions.

In addition to understanding the tradeoffs better if you have a technical background, if the project manager has to ask a technical member of the project team every single time the customer asks a technical question, the customer will start to lose confidence in the project manager. Surely the project manager shouldn’t be expected to answer every single technical question asked by the customer, and in many cases before the project manager answers the question he or she should say something about confirming the accuracy of the answer with the technical team. But if the project manager can demonstrate to the customer a good understanding of the technical issues of the project, the relationship between the customer and the project manager will improve. Lacking such a level of technical ability, I’ve seen instances where a customer has started to contact members of the technical staff directly without involving the project manager.

That is the path to chaos. If the customer is contacting the developers directly, that customer could be hearing commitments and getting answers to questions that reflect real scope changes in the customer’s expectations of what the solution will ultimately contain. Clearly that should never be allowed. But the customer will be tempted to follow that path if they need an immediate answer to a question and they don’t have confidence that the project manager can provide that answer.

A technical understanding is a valuable asset with any level of management within a software development company. This goes all the way up to the top of the organization.

Joel Spolsky is a software developer, living in New York, who writes about software development, management and business on the Internet. Mr. Spolsky says this:

“If you ask me, and I’m biased, no software company can succeed unless there is a programmer at the helm.”

I wouldn’t go that far. I think that managers who are not technical but willing to take advice of technical people can certainly succeed.

But I certainly think that it is difficult for a software project to succeed without a technical person, particularly a programmer, leading it. (But then, like Mr. Spolsky, I may also be a bit biased.)

It's possible to have too much education

"Too much" education is a characteristic that is really more applicable to custom software development than it is to standard software development.

If you review the definitions of standard and custom software Standard software programs provide the basis for the custom software development. Not all standard software requires customization. Game software, for example, isn’t customizable.

In other words, people buy standard software because of how “cool” it is.

People buy custom software because it solves a specific problem. Customers want that problem solved, but they want it solved efficiently – i.e. they want it to work, but they want it to work cheaply.

People with advanced degrees in fields like Computer Science are really good at making things “cool”. They are knowledgeable in the latest and greatest trends and techniques in the computer industry and (generally) know how to implement them. So if you are selling something as the “coolest” product on the market, the programmers with the advanced degrees can surely help.

But to the customers of custom projects, “cool” isn’t as important as “cheap”.

My first job after college was working in an instrumentation department for a large manufacturer. (“Instrumentation” is equipment designed to test the products produced by manufacturing.) The instrumentation department consisted of both degreed and non-degreed engineers so I had an opportunity to observe engineers with both types of educational levels.

In all honesty, the non-degreed engineers were better suited to that particular job. Those engineers merely wanted to get something to work. They would start by trying to find something in past designs that worked and reuse that design wherever possible.

At one point an engineer with a Master’s degree was hired to work in the department. That engineer was not content with simply reusing designs that had worked in the past. The new engineer wanted to use the “latest and greatest” techniques and products. Unfortunately those new techniques were more expensive and they also took more time to implement.

The same factors are important in custom software design. While the phrase, “Uses well-tested three-year-old technologies” may not be a very effective sales pitch with standard software, it works very well with custom software.

So the key of custom software (and hardware) is: make it work; the cheaper the better. In my own experience, people with advanced degrees tend to overlook this basic precept.

Having said all of that, I believe that having some formal education in computer programming is very beneficial. I worked with one computer programmer, who actually had an MBA. He was very bright. He had started programming computers as a hobby, and then when he discovered how much he enjoyed it, he changed his job within the company where he worked and went from manager to programmer. However he had never taken a formal course in computer programming. There were many techniques that he didn’t know. For example he had never heard of an “iterative loop” (an “iterative loop” is a block of code within a computer program which is executed repeatedly in order to work on successive parts of a problem resulting in an efficient solution to the problem).

Implications:

A Bachelor’s degree is something to look for in all software development environments. But be suspicious of higher degrees, at least when working on custom software development projects.