The Economics of Web Service Development
by Marcia Gulesian
|
Pages: 1, 2
Project Management
Project management differs from more traditional management activities, mainly because of its limited framework, which gives rise to a host of rather unique problems. Projects go through a series of stages. During this life cycle, a variety of skill requirements are involved. And projects bring together personnel with diverse behaviors and knowledge and skills, some of whom remain with the project for less than its full life.
The project manager needs to be effective in planning, scheduling, and controlling and identifying risks. An interesting account of how to manage risk on software projects (and provide minimum-cost downside protection) can be found in Waltzing with Bears.
I lean in the direction of having no unnecessary measurements (a.k.a. controls) in project management. The key word is "unnecessary." Project managers employ tools (such as GANT or PERT) to obtain:
- A graphical display of project activities.
- An estimate of how long the project will take.
- An indication of which activities are the most critical to timely project completion.
- An indication of how long any activity can be delayed without lengthening the project.
The idea is to show interrelationships among activities. But many projects are subject to "change orders" as the work proceeds, whereby the final product has features different from those originally planned. Obviously, changes in scope can also affect quality, schedule, and cost. So quantitative tools for project management can be used without factoring in human behavior to the extent that it needs to be.
The Mythical Man-Month and It Sounded Good When We Started offer useful insights for working with people on projects. And, finally, you may have heard an experienced project managers quote the maxim, "A carelessly planned project takes three times longer to complete than expected; a carefully planned one takes only twice as long."
Development
The developer (or the person who makes technology decisions for him or her) must decide on the language, framework, platform, and tools to be used in the development of a web-services (or any other kind of) application. These can be tricky choices. Sometimes they're made for personal, not business reasons: made in support of an individual's career-advancement goals, out of intellectual curiosity about the latest technology to catch the developer's eye, or even based on nothing but marketing hype.
Equally far-reaching are decisions made in the selection of programming methodology: old-fashioned, fly-by-the-seat-of-your-pants (preferred by many), or the sometimes oversold RAD and XP. Taken by themselves, neither of these choices assures the best outcome. However, when considered with other factors -- such as the match of the individual developer's skill sets to the needs of the project, her views on and needs for more or less management, and individual motivation -- logical choices can be made.
Remember, there's a cost to every decision. With RAD, for example, does the software you deliver sooner mean that your customer must accept a product that is less usable, less fully featured, or less efficient? That is, will lower development costs also mean a lower level of customer satisfaction?
Job Design
Good job design is not easy. As jobs continue to evaporate in the post-dotcom era, low morale among IT workers is increasingly threatening productivity, according to a recent study by research and consulting firm Meta Group of Stamford, Conn.. They reported that 71 percent of IT managers surveyed indicated that IT employee burnout is currently a serious issue in their organizations.
So, it's more important now than ever to design jobs -- at every level of your organization -- with not only a logical approach that doesn't consider satisfaction of wants and needs and a behavioral approach that does. A job description that calls for specialization such as only Java or only C# allows the programmer to concentrate her efforts and thereby become proficient in some aspect of the task.
For some, however, this narrow scope can be dull, downright boring, and the source of dissatisfaction. On the other hand, some workers prefer a job with limited requirements and responsibilities and are not capable of handling jobs with larger scope. So, matching the developer's personality and skill set to his or her job can go a long way toward maximizing productivity and quality.
Other Issues
A number of other issues affect each level of the hierarchy. One, interrupted or successively different job assignments, arguably affects the developer more than other members of the hierarchy. Interruptions in concentration create the need to relearn. They occur when jobs are split or when an expedited job interrupts an existing one.
While the amount of forgetting may be difficult to estimate, the restarting rate for your return to an interrupted task can be material. In contrast, when successive jobs are not interrupted, but simply different, there's no forgetting. In the latter case, it's all about learning. In either case there's a startup cost.
Another issue is management style. It has a direct effect on every individual in the organizational chart and affects the bottom line. I'll concentrate on the opposite poles of a hands-off management style (a.k.a. university) and a micro-managed (a.k.a. kindergarten) management style.
When the former is paired with skilled workers who like their jobs, creativity is often the result. The other extreme -- the micro-management of under-skilled or unhappy workers -- is frequently a good idea. But, the micro-management of skilled workers who otherwise like their jobs can sometimes prove to be counterproductive. You may have your own examples of the latter. And, many professionals experience excessive attempts to control their behavior, which can cause resentment.
Contrast this with Peter Drucker's idea, that "a manager's job is to make people's strengths effective and their weaknesses irrelevant." In some environments, managers even encourage employees to risk making mistakes and create an atmosphere that encourages them to be open when errors occur. After all, you have to make mistakes before you (and everybody else) can learn from them.
Cost of Federal Regulations
Federal regulations, particularly those concerning confidentiality, affect the bottom line in every industry. The biggest driver of security technology in the healthcare space is the Health Insurance Portability and Accountability Act of 1996 (HIPPA), whose final rules took effect on April 21, 2003. It includes a set of provisions to move a number of administrative healthcare functions online.
The U.S. government has mandated that healthcare entities, which deal with a large amount of confidential information, must gradually increase their HIPPA-compliant volume of transactions. The emergence of standards such as web services (and HL7, an ANSI-accredited standard widely used to interface the independent systems in health care institutions concerned with clinical information) can help these organizations achieve HIPPA compliance and re-architect their internal applications infrastructure with less disruption than traditional approaches.
While there's a cost benefit when you implement HIPPA-compliant, web-services apps correctly, there can be a steep price to pay when your software fails to meet HIPPA's rules on privacy and the like. Noncompliance can cost your organization thousands of dollars a year in penalties and a violation of the Act's privacy provision for personal gain or with malicious intent can result in a fine of up to $250,000, imprisonment for up to10 years, or both.
And, of course, there's also the risk of civil suits. This privacy rule is expected to cost the health-care industry $17.6 billion over 10 years, according to the preamble of the regulation.
HIPPA is for the most part technology neutral and digital signatures are not presently required. However, without the use of PKI, confidentiality, message integrity, access control, non-repudiation, and end-entity authentication is difficult to achieve.
Key factors to use when estimating the cost of putting a PKI infrastructure in place are number of users, number of applications, and whether the Certifying Authority (CA) service is being outsourced or managed fully in-house. If the cost of certificates or related infrastructure services exceed 10 percent of the overall cost of an application, then a positive ROI becomes increasingly difficult to achieve. Naturally, to determine the real cost of PKI, you have to amortize all software, hardware, consulting, and other hidden costs of deployment.
Biometrics have become interesting for the healthcare industry because they're inexpensive, mobile, and [relatively] secure. But, biometrics by themselves don't solve HIPPA compliance issues. It takes a digital certificate to achieve non-repudiation with a digitally signed transaction. However, by combining a digital certificate with a biometric device, you can achieve good security practices and HIPPA compliance for many healthcare organizations' tasks.
Total Cost
The notion that "time is money" has been understood from ancient times. So, while the consumer of a cost-saving software application may want to receive it as soon as possible (minimizing "delay costs"), the development team may not want to speed up the project (minimizing "crashing costs"). Management needs to strike the appropriate balance -- on a case-by-case basis -- between these competing interests.
In addition to those mentioned so far, other costs frequently need to be considered (or disregarded):
- Sunk Costs -- Costs of past investments that cannot be recovered. They have no relevance to new investments.
- Overhead Costs -- The best way to determine whether overhead costs should influence the project-selection decision is by estimating the incremental overhead cost, or the difference in these costs with and without a particular (proposed) investment.
- The Cost of Money -- A very important factor when considering the long-term costs and benefits, especially through periods of high cost of capital.
A discussion of the post-completion audit is necessary in any treatment of capital budgeting. The post-audit involves (1) a comparison of actual results to those predicted in the investment proposal, and (2) an explanation of observed differences. The post-audit has several purposes, including improved forecasts and improved operations.
But the predicted results are based on probabilities and the actual results sometimes fail to meet expectations for reasons beyond the control of the people directly responsible for the outcome, as well as for reasons that no one could realistically be expected to anticipate. So, if the post-audit process is not used carefully, management may be reluctant to suggest potentially profitable but risky projects.
Economic benefit from employing any emerging software technology is possible when the processes of development and deployment are managed well.
Conclusion
By focusing too much on technology and not enough on whether you're actually solving a business problem (as opposed to simply automating a flawed one), what makes people tick (their individual wants, needs, and skills), and the hidden costs of compliance with governmental regulations, you can wind up squandering precious resources. In the process, you can dampen the enthusiasm of senior management for a new technology such as web services, which, if properly introduced, can improve your organization's ability to do business.
The most important goal for any software development group should be to achieve customer satisfaction. This will be done by producing end-deliverables that satisfy, and hopefully even exceed the customer's expectations. But, a separate consideration and the real driver for software development should be total cost of ownership. Your organization should produce results that are economically justified, not ones that simply enable bragging rights to having adopted the latest technology.
