People and Money

It is fairly clear that building custom web applications and web sites requires talent and money. It is not possible to introduce the whole cast of characters but a few of the main players can be described. And we end this on the topic of budgets, why quality is not really a project variable, and why time is roughly equivalent to money.

Building a Web Application

Beginning with a Concept
Analyzing Use Requirements
Designing the Domain
Building the Domain
People and Money

return to the leakyboat



I am not convinced there is such a thing as a "typical" project. The various competencies listed may be found in full time or part time or temporary staff, and a number of these competencies may be found in the same individual to be used throughout the project in a variety of capacities and tasks. Larger "enterprise" projects are commonly populated with "specialists" or people who can do one or two or three things very well. Smaller projects are commonly done and run by one or two people, soup-to-nuts, beginning-to-end, top-to-bottom.

The following list identifies the primary competencies that are commonly required to design, develop, maintain, and enhance a domain with business applications. This list does not necessarily specify the  staffing requirements of a typical project .

It is usually very telling for a buyer of design and development services to ask about the requisite skills needed to complete the project. The design and development expertise is usually, after all, the largest share of the financial purchase cost of a project.

The analysts, designers, developers, artists, engineers, testers, trainers, writers, and managers may well be engaged in complex exercises that require uncommon expertise. But it ain't magic...

  • SUBJECT MATTER EXPERTISE is the knowledge of user roles, responsibilities, and business competencies that allow users to effectively and purposefully interact with the domain and its applications. Subject matter experts (SMEs) can describe the information critical to decision-making in the domain as well as the dynamic in which that information is used. This is important to the design of the system and for confirming throughout the project that the domain's information and communications services maintain a high degree of fidelity with the realities on which the domain is based.

  • BUSINESS ANALYSIS is the definition of process and business rules through use cases that allow system designers to model and developers to create the application structures, logical processes, and user navigation within the domain. There is usually a mix of business and technical expertise here. The primary deliverables of business analysis are functional and technical specifications or the "construction documents" of the domain.

  • CREATIVE DESIGN is the collaboration with system designers to develop "look and feel" and to fill out the logical plan to develop user interface. There is usually a mix of graphic and functional design, digital art, communications, style, and process skills at work in this expertise.

  • DATA STRUCTURE DEVELOPMENT is commonly performed by a data architect or a data modeler in collaboration initially with analysts and designers, and subsequently with programmers (although later adjustments, if required, are usually performed by a database administrator). The expertise here is based in an understanding of the RDBMS environment, the ability to read and understand the functional and technical specification, and to anticipate the requirements of the programmers.

  • DATABASE ADMINISTRATION is pure engineering. And unlike most other staff, the ongoing presence of a competent database administrator will be fairly essential if an industrial-strength RDBMS environment is installed. For that reason, it is usually worthwhile to seek a database administrator with a broader engineering skill set to include, say, network administration and the like.

  • DEVELOPMENT PROGRAMMING is the laying down of code and assembly of network software service components. Expertise in programming is fairly well defined according to the selected environment. The need for this expertise will be defined by the functionality specified. If the construction documents (functional and technical specifications) are complete and precisely drawn, programmers will be efficient and low maintenance, assuming that their skills and experience qualify them as competent. If the specifications are not complete, programmers will either spend more time asking questions than programming or they will be building what they think you want (and far too often that is not what you had in mind).

  • QUALITY ASSURANCE (QA) testing has two primary objectives. First is to ensure that the developed result has been built to design specifications (and if it has not, that the result can be fixed or properly evaluated to determine whether the performance of the actual result can be favorably compared with the intended performance). Second is to ensure that the developed result performs to design specification (i.e., the process is not flawed by design or coding errors). Quality assurance is commonly performed by the same business analysts who designed the system in the first place because of their knowledge of the design. The QA process should be started as early as possible in the development period to fix problems as soon as possible after they may be discovered. In any event, programmers should never be given the responsibility to test and evaluate their own work.

  • TRAINING may be necessary to ensure competent administration of the domain. If everyone has done their job properly by the time that the domain is built, the applications should be easy and reasonably intuitive to use, and training of the users out on the public network should not be a significant issue. But training may be required for internal non-technical staff that must support and manage the domain, its data and content. Ideally, these staff will be included in review and testing of the domain and will acquire their knowledge and skills thereby. More disciplined and structured approaches to training may require basic understanding of instructional strategies to be effective.

  • DOCUMENTATION (TECHNICAL WRITING) ensures that knowledge and skills

    ...Although I have only rarely been impressed by the writing skills of most software engineers

    related to the management of the system continue to exist despite staff turnover and absence over time. User documentation can come from the work of business analysts, designers, and QA. Technical documentation can come from business analysts and  engineers .

  • USER SUPPORT proves the value of training and documentation. Support functions cannot be considered credible or effective if support staff do not know

    User support has a primary role in helping users. But it also has a major role in on-going quality assurance. Most problems with the domain will be reported to user support. Support should have free and open communications with software engineers to make certain that those problems are resolved.

    or understand the domain, the way it operates, or cannot find that information efficiently. A support organization requires the imposition of special rigorous disciplines for sharing information among themselves and with others in the enterprise. Support is not only responsible to improve the user experience and understanding of the domain.  They are also the primary means by which future enhancements to the domain and new development initiatives are influenced. 

  • PROJECT MANAGEMENT is the competency that shepherds all these other competencies toward the project's goals and objectives, all the while measuring the opportunities for, the threats to, and the risks of the project and its timely and economic completion.


The first factor that determines time and expense of any project is the desired result and the amount of effort (and, to a somewhat lesser extent, the equipment, materials, and tools) required to create that result. As suggested earlier, the accuracy of a time and cost budget projection is entirely dependent upon the quality of the domain's blueprints found in a functional and technical specification.

People generally want three outcomes when building an information system:

  • Low cost

  • High operational reliability (i.e., quality)

  • Immediate implementation

As a practical matter, only two of these three outcomes are ever possible to attain in any given effort.

It is easily argued that high operational reliability is the variable with the least flexibility. It is generally recognized that an information system that is unstable or high maintenance or outright broken is worthless, regardless of cost and time to develop and deploy.

And so that leaves time and cost: more time means lower cost and less time means higher cost. Take your pick...

Return to Top.

web application development, project staffing, development competence, subject matter expert, business analysis, process design engineer, analyst, creative design, database developer, RDBMS administration, programming, programmer, software engineer, quality assurance, testing, technical writing, user support, project management, project cost, time budget