A1. Do you give fixed-price bids?

We can give fixed-price bids in cases where project requirements and scope are well-understood. But although a fixed-price bid in theory guarantees a known cost for a project, this approach has limitations and is not necessarily in your best interest.

When a software developer agrees to a fixed-price, it is in relation to a specified scope of work. Whenever scope is clear and unlikely to change, fixed-price can be a good approach. But that’s not typically the case. Most business applications begin from a desire by the customer to explore the possibilities of the new application, including such questions as: How can I get the most leverage from the new software? What new information can be available to me? How can I reduce workload and improve efficiency of my staff? How can I improve service for my customer? How close to "real time" can my view of my business be?

On the other hand, after the requirements and external design have been documented and accepted, the remaining scope of a project is much more predictable. At this point we often give a fixed-price or not-to-exceed estimate for the remaining design and implementation work. If additional features or changes are requested, we can simply track them as separate tasks from the main project. This approach gives you the protection of a firm cost estimate , but retains the flexibility to make changes if necessary.

A2. Why is custom software so expensive?

The answer is a bit more complicated than the question. All software is expensive, and in an absolute sense, of course, custom software is usually much less expensive than product software—it's obvious that an application like Microsoft Word or Excel costs many millions of dollars to develop, but is relatively inexpensive to buy because its cost is spread among millions of customers.

Custom software is created for a very limited number of customers—usually one. The key, of course, is to develop custom software only for specific needs not met by off-the-shelf products, and where there are tangible economic benefits. In many cases these benefits are sufficient to make custom software at least as cost-effective as off-the-shelf software. There are other advantages, too, including the ability to modify or extend the software as your organization grows or your needs change.

Other useful questions would be:

• If I need custom software, how can I maximize its effectiveness—how can I fully exploit this opportunity to blend our business processes with new software in order to boost the productivity of our personnel, reduce our costs, and improve service to our customers?
• How can I be sure the software we develop is reliable and a pleasure to use?
• How to insure that the software is flexible and adaptable for future needs?

In other words, how can I make sure the money we do spend on custom software is well-spent?

As software developers, our job at Eagle is to deliver the right answers to these kinds of questions. The essence of our work is to create cost-effective software of exceptional quality and utility. When that effort is successful, custom software may not seem so expensive after all.

A3. How can I reduce the cost of my project?

There are many aspects to project cost, but let’s take it from this point of view: “For a given finished product, how can I as the client minimize total cost?”

Here are some of the more effective things you can do:

• Help get the requirements right. If you have time, do your best to state in your own terms all of the requirements for the new software. In any case, give especially good support to the developers during the requirements phase of the project. This is the most important step in the development process—everything that follows depends on it.
• Refrain from making unnecessary changes. Once there is a clear conception of “version 1” of your software, avoid asking for changes to this version unless absolutely necessary. It's usually more cost-effective to accumulate ideas for enhancements and changes and then deal with them after the first version has been in use for a reasonable period of time.
• Avoid artificial deadlines. As developers we will give you at each stage of the project our best estimate of the time required to complete the remaining steps. Sometimes there is a belief that a way to “get things done” is to simply set a deadline and insist that everyone live with it. This can not only lead to greater cost but can also lower the quality of the software. This is especially true during the requirements and external design phases of the project. The entire team—meaning your stakeholders as well as our developers—needs time to communicate accurately, digest, reconsider and explore the best options for your software. This is not wasted time nor does it indicate a lack of discipline. It is the least expensive way to arrive at solutions that go beyond the obvious—innovations whose marginal cost is low but whose marginal utility is great.

A4. How do I relate work accomplished to the invoices you send?

Eagle uses a proprietary Project Management System—called Manage!—that integrates time reporting, billing and project planning into a single system. For every project we create a detailed project plan in Manage! As the project progresses, each developer records in Manage! their time spent on each task along with a description of the work performed. Based on this information, invoices are produced for each billing period along with supporting timesheets showing exactly what was accomplished by each person on each task and when the work was performed. Using the same database, Manage! also produces updated project schedules and projections, as well as time and cost analyses for each part of the project.

A5. I’m responsible for the budget in our organization. Once the budget has been set, there is low tolerance for “surprises.” How confident can I be regarding your ability to deliver the promised results within the agreed-upon budget? What is the likelihood I’ll have to go back to my board for more funding?

This is addressed in part by the answers to earlier questions. Beyond that, there are several key points to keep in mind:

• One of the keys to avoiding "surprise” is to have a well-defined project scope. Arriving at a scope definition is a team effort, involving both developers and stakeholders. If the team creates a statement of scope that is clear, sufficiently detailed, and appropriate to the goals of the project, the likelihood of later “surprises” is greatly reduced.
• Another important key is to track and evaluate project progress on a week-by-week basis from beginning to end. This means that when the project begins, there must be a specific estimate of effort for each part of the project. All work performed must be tracked by related part. Then the relationship between percentage of “completion” must be compared regularly with percentage of “resource used.” Based on this evaluation, corrective action can be taken early when necessary, thereby greatly reducing " surprises" late in the project. This sounds extremely obvious, of course, but the real surprise is that developers often fail to track projects this way. (This is discussed in more detail in the the Project Management section of the website).
• Finally, make sure that the person in your organization who is assigned as liaison with Eagle stays involved and keeps you candidly informed about the status of the project. As mentioned earlier, stakeholders and developers are one team—it’s essential that they share a common understanding of project status and goals—and problems, as well—throughout the life of the project. Sometimes “surprises” to some members of the team are simply facts that others have been aware of for some time.

A6. I expect to have a series of relatively small projects over the next year or two. I like the proposal you’ve given me for the first project, but I’m concerned that later on your proposals for new work will be less rigorous—in other words, once I’ve become somewhat dependent on you, I’m afraid your pricing won’t be as favorable as it was for the first project.

We have a standard method for estimating projects, which we always use, whether this is the first or tenth time we have worked together. Our estimates list in detail the tasks required for the project and relate these tasks to deliverables. All time and cost estimates are explicitly described. You can easily see how the estimate was arrived at and where there are opportunities to reduce cost or scope.

In addition, we normally work on a time-and-materials basis, so the cost will be based only on the actual time required to do the work. All work is meticulously described in our timesheets, and is tied to the specific tasks which make up the project.

A7. Our company definitely needs certain custom applications to help improve the efficiency of our organization—better control of costs, streamlined operations, and so forth. But our senior management is “old school”, so to speak, and doesn’t understand why our application should cost nearly as much as you say it will. They would prefer that we meet these needs with standard off-the-shelf tools like Excel, Outlook and Word. How would you respond to their point of view?

As far as tools are concerned, products like Excel and Word can be customized to serve a wide variety of needs, but they aren’t designed to be general purpose tools for creating custom business applications. In the long run, if you are creating a custom application, you have much more flexibility, reliability, maintainability and better performance if a conventional development platform is used (such Java, C#, Visual Basic or C++ in conjunction with web-oriented tools).

Whether a custom application will be cost-effective for your organization is something you and your management will have to judge. However, I can mention a few significant benefits of custom software which are often overlooked when making this kind of decision:

• Custom software can “institutionalize” certain business practices in your organization. In other words, by having appropriately designed software, your users can be guided through certain processes in a way that encourages consistency and accuracy. This is especially helpful for employees who are new to your organization or are occasional users of the software.
• The impetus for creating a custom application is often related to a desire to control costs or improve customer service in specific ways. When objectives are clearly described, software can be designed very effectively to meet those specific needs. In other words, the scope of a custom application should consist only of what's needed to provide specific planned economic and operational benefits.
• Custom applications are “enablers” which, once in operation, can open up entirely new opportunities that weren’t possible or even conceived of before. In other words, once certain business practices are supported consistently and reliably by an application, you then have an opportunity to take further steps which would not have been possible—or even thought of—before the application had become part of your business process.

Here’s a relatively simple example: We created an integrated membership and program participation system for the YMCA of San Francisco. The system is web-based, with all member and program data for 15 branches stored in a single integrated database. Prior to our system, the YMCA’s legacy system was a network-based system with a non-GUI interface and a separate database for each branch’s data. After this system was implemented it became possible for the YMCA to offer system-to-system interaction with a business partner via web services. This was not one of the original goals of the system. It is just one small example of a valuable second-level opportunity which was thought of only after the “enabling” properties of the application had become apparent.

C1. Because of the number of stakeholders we have, their varied roles in the organization, and their different levels of sophistication regarding software development, I’m concerned that communication between them and Eagle may be unmanageable, leading to an unsatisfactory work product, extra cost and/or delays in the project.

This is a common situation, and our approach to development takes this into account.

First, although we collaborate with all your stakeholders as needed, it is important to appoint one person from your staff to act as project liaison. They will act as the ultimate “approver” of the steps in the development process. This helps keep everyone on the same page and avoid miscommunication.

Secondly, our project specifications are designed to document—clearly and accurately—the common understanding reached by the team, stakeholders and developers alike. These specifications include such documents as the Requirements Analysis, Risk Analysis, Problem Domain Concepts and Vocabulary and the External Design Specifications. In other words, even though there is inevitably some apprehension about disorder as a project begins, the transformation into order begins immediately and results in documents which everyone can understand and agree on. Working effectively with stakeholders having a variety of backgrounds, training, points of view and opinions is a key part of our job—and we enjoy it. Especially as members of the team begin to see form emerge from the process.

C2. Our application needs are complex. We currently perform very sophisticated analyses of certain corporate data in order to determine appropriate actions to take now and in the near future. Currently we are doing this through a combination of legacy systems augmented by “manual” analysis (spreadsheets, and so forth). We need a new system which integrates, extends and streamlines this functionality, but we are very concerned about your ability to really “get it right” with regard to our business rules and our reporting requirements. How can we have confidence you can do this?

That’s the key question in all software development. In your case, because of the complexity of your application, you obviously need to know in advance that the product will be a bullseye with respect to your needs.

As usual, the answer has several parts: how our methodology insures “fit to purpose,” the exceptional experience and skills of our developers, and our track record, which confirms the efficacy of our methods and skills.

As described in the pages on Development process, the primary goal of the first phase of development is to be certain we are creating the right product. This always needs to be questioned—even when the client believes he knows exactly what he wants. As a generalization, it’s more true than not to say that the requirements for an application are never understood until the project has begun in earnest. All assumptions and beliefs must be suspended until they have been exposed to careful consideration by the team. This sometimes seems a little “over the top” to a client, but the alternative is that one or more invalid assumptions find their way into the requirements and lie there innocently until deployment—when their inappropriateness becomes visible to all. With good leadership, getting the requirements right in the first place simply requires a little time and good-faith participation by all members of the team. Not getting requirements right leads to costly redesign and reimplementation, bad experiences for users (who may in fact be your customers), delays in deployment of a usable system, lowered morale of team members and other negative consequences everyone has seen at one time or another.

So, methodology is one thing, but understanding methodology and applying it appropriately in “real life” is another. Without the actual experience of implementing many software applications, it’s impossible for a developer to truly understand the significance of best practices in software development. Eagle's development managers and project leaders have many years’ experience creating custom software. They understand very well that skillful execution of “methodology” in the real world brings a project to life, just as an orchestra transforms static notes on a printed page into something that is whole and alive.

But after all the words, actions are what count. We have been consistently successful for many years in doing what I’ve described above. Some examples are described on the Project section of the website. And we’ll be glad to put you in touch with some of our current and former clients if you would like to ask them about the work Eagle has done for them.

C3. My department head has assigned me to work with the software vendor for our new application. I’m not trained in software development or project management, and I’m very concerned that, in spite of my best efforts, the project may not come out the way my manager expects. How can we deal with this situation?

Your question is similar to the two previous ones, and I think those answers apply to your situation.

I would just add these comments to what has already been said:

• It’s the developer’s responsibility to create documentation which you and other stakeholders can understand. If any of the documentation—especially the requirements and the description of the problem domain—aren’t completely clear and acceptable to you, then you should insist that the developer go back to the drawing board and try again. If the documentation at each stage of the project doesn’t make sense to you, don’t allow the project to go on to the next step.
• Insist that the developer meet with you weekly to give you a status report on the project. You should be shown, for each component and each task in the project, how many hours have been worked to date, the estimated effort for completion, a projected completion date and projected total cost. Getting this information weekly helps you see right away any project slippage, either in terms of dates or cost. If progress on the project deviates significantly from your expectations, you will be able to bring the developer together with your management and work things out before there is an unpleasant “surprise.”

D1. Have you ever botched a development project?

Not as a final outcome. But any developer who hasn’t encountered problems with a project hasn’t been in the business very long.

Virtually every project has its challenges—that’s why millions of words have been written about dozens of different methodologies. In fact, software development seems in some ways like extreme white water rafting—if you fall asleep at the paddle it's all over.

We are glad to say that the great majority of our projects are completed without significant difficulties. I’m especially glad I can say that—even with the few occasional and inevitable “problem projects”—we have always delivered the goods in spite of problems encountered. And we have stood by every project with our 2-year warranty—without exception.

D2. Has your 2-year warranty ever come back to haunt you?

No. We stand behind every project, and if any warranty work is required, we do it gladly and quickly. Obviously, our ability to honor our warranty is based on delivering a high-quality work product in the first place.

D3. How do you insure that your applications are high-quality? What does “quality” mean to you when it comes to application development?

Put briefly, “quality” in a software application means to us:

• it has excellent “fit for purpose,” it really does what you need and expect it to do;
• it has good performance;
• it is reliable, produces consistently valid output;
• it is easy, intuitive and enjoyable to use, does not require training, does not intimidate users;
• it is maintainable and extensible, can grow in a controlled way to meet future needs and accommodate desired enhancements.

Although “quality assurance” is an essential part of our development process, all of the above aspects of “quality” depend on the development process itself, especially the beginning phases of the project. “Quality assurance” is just the process of checking that quality is already built in to the product—and it better be, because it’s usually cheaper to start over again than to put “quality” into a product that doesn’t have it.

If we do a good job in determining requirements, defining the problem domain, assessing risks, creating a clear, understandable user-interface and meaningful outputs, then we’re laying the essential foundation for quality in the finished product. These aspects of our development process are discussed throughout this FAQ section and in the Methodology section of this site.'