The Organic Software Engineering Approach (OSEA) is a new innovative approach for realizing software systems. It significantly decreases software development costs, maintenance costs, project cancellations, and cycle times. It also increases business effectiveness, productivity, satisfaction, and software quality. The OSEA virtually eliminates the software project horrors and always meet commitments. More importantly, the OSEA increases customer value, satisfaction, and productivity. Finally, it virtually eliminates offshore development because it is a business centric software engineering approach that depends upon a “face to face and eye to eye” level of coordination, collaboration, communication, and cooperation with the business customer. Offshore development companies cannot feasibly provide this level of collaboration.
Every segment of our society will benefit starting with a more a productive economy and the return of millions of offshore software jobs. The DOD will experience significantly reduced weapons systems costs and increasing pool of software engineers. Senior executives in major corporations and government will experience major decreases in the software budget and enhancements to the business units through more cost effective systems. Unemployed software developers can now go back to work and our universities will overflow with computer science majors.
However, this report is about reducing software development costs by a factor of ten. In order to achieve our cost reduction goals, the OSEA addresses four high cost areas: software rework, excessive functionality, software complexity, and low staff productivity. Hypothetically, take a project budgeted at $20 million. The following reductions in rework and excessive functionality and increases in project efficiency and staff productivity will decrease costs to around $2 million.
Reductions in Rework
First, reduce the 20 million dollars by 40%. The rework ratio is the cost of implementing immature systems that must be fixed in immediate post development maintenance, about $8 million. The rework ratio represents the quality-related costs associated with difficulties in meeting cost and schedule targets. In 2003, a US Government Accounting Office (GAO) study indicated that the DOD software budget was 21 billion dollars of which 8 billion (40%) was wasted on software rework due to schedule and quality issues. A report, “The Challenges of Complex IT Projects” from the UK
These are the costs associated with the “schedule-first” objectives and the resultant creation of “Fix-it-in-maintenance” cultures. When projects fall too far behind schedule, software projects will often make system decisions based upon schedule considerations rather than technology, quality, and customer considerations. The decision to implement an immature system that must be matured in maintenance is an example. It represents the waste associated with doing it right the first time in development and fixing the system in maintenance at many times the costs. These costs are the “Software Black Hole” of immediate post implementation activities. Often these costs are not allocated to the development budget and thus disproportionally distort the true software development costs.
Reducing software waste represents a major increase in software productivity. Cancelled software projects, unused systems, and the rework required to make immature systems operational incur tremendous project waste. According to studies from Caper Jones, 60% of software work is engaged in fixing errors that could have been avoided. Software engineers spend only 25% of their calendar time on value-added activities such as developing new software systems or enhancing current software applications. Large projects that are cancelled usually accrue costs of more than $1,500 per function point and are about 12 months late when they are cancelled. 48% of projects over 10,000 function point and 65% of projects over 100, 000 function points are cancelled. Often there is a complete write-off, without any positive value. For example, the cancelled FBI Trilogy System costs $170 million before it was abandoned.
Reductions in Excessive Functionality
Take the remaining 12 million and reduce by 60% the costs associated with excessive functionality, about 7.2 million. Project costs are now 4.8 million. The 60% comes from a 2002 Standish Group International study of 100 companies. It found that 45% of application features are never used, 19 percent rarely used, 16 percent sometimes used, 13 percent often used, and 7 percent always used.
Excessive functionality is also a major source of waste. Managing marginal and reducing excessive functionality reduce system size and complexity which exponentially reduce project resources. Included are effort hours, duration, staff count, development costs, cycle time, deployment, and maintenance costs. Under the traditional software practices, project teams seek to deliver all the requirements in a monolithic manner. Users tend to identify a full set of requirements including everything on their wish list. The integrative and recursive process that realizes software in different stages of complexity until the project is complete replace the monolithic linear process because the former provide feedback, organizational learning and project control. When the system is delivered much of the feature set goes unused because the features are not required, the users are overwhelmed with too much functionality, or the quality of the system is so poor that the users are afraid to explore beyond absolutely what is needed. The system is complicated by the creation of a system architecture that is based upon unused requirements.
Increases in Project Efficiency
Take the remaining 4.8 million and reduce by 40% for improved project efficiency through less complexity and difficulty. Minus the $1,920, 000 now leaves $2,880,000 as actual project costs. The 40 percent increase is the significant increase in productivity that comes from reductions in project management and software engineering complexity and difficulty. Fred Brooks asserted that software engineering is inherently difficult because it is very complex. This inherent complexity causes difficulties in communications that, as Brooks states, increases software defects, cost overruns, and scheduled delays.
The replacement of monolithic machine practices with evolutionary organic software growing practices that emulate living, biological systems will significantly reduce software complexities, difficulties, and problems. Generally, biological systems contain vertical, multi-level relationships in a system hierarchy. Think in terms of cardiovascular, endocrine, digestive, lymphatic and respiratory systems. Biological systems are also self-organized systems where each system supports body functions. For example, the respiratory system is the system of organs in the body responsible for the intake of oxygen and the expiration of carbon dioxide. In mammals, it consists of the lungs, bronchi, bronchioles, trachea, diaphragm, and nerve supply.
Organic design use software functional elements to structure projects and systems like biological organisms. As biological systems are mapped to specific body functions, software functional elements are also mapped to specific business elements and business units. Software functional elements are the new basic software function and appear as systems, subsystems, software functions, capabilities, and features. Biological design create objects that can visualized as a stratified tree with a trunk, limbs, branches, twigs and stems. Software functional elements are also stratified where the system is the trunk, the limbs are the subsystems, the branches are the software functions, the capabilities are the twigs, and features are the stems. Software functional elements as a stratified tree significantly increase system visualization, requirements conformity, and requirements changeability. All of which significantly reduce software development complexity and difficulty.
In traditional software development practices, black boxes have no specific ownership and cannot be visualized or mapped to a specific business elements or customers. The intermingled, tightly coupled requirements inside the black boxes make machine objects very complex, difficult to code, hard to test and very defect prone. Conflicts occur over requirements definition and scheduling issues. In the project equivalent of organic design called distributed project management, software subsystems are allocated to specific developer and user teams to manage and develop. This makes requirements definition, system design, coding, testing, deployment, support, training and maintenance easier. Project management is made easier through fewer meetings and conflicts, less management intervention, better decision-making at the point of action and control, and shorter decision cycles.
Increases in Staff Productivity
Now, reduce the remaining costs of 2.88 million dollar by 30%. That is the cost of low staff productivity, which is about $864, 000, leaving total project costs of approximately $2,016,000. Many software developers are notoriously unproductive because the management factors negatively affect morale, motivation and productivity. The problem is the application of scientific management to software project management. Henry Gantt developer of the Gantt chart, in the 1910s, is the forefather of project management in this country. Much of Gantt’s work was based upon his friend Frederick Winslow’s Taylors theories of scientific management. Taylor was also the leader of the Efficiency Movement that in the early 20th century sought to maximize efficiency through the identification and elimination of waste, usage of time and motion studies, and the implementation of best practices. Taylor ignored aspect of human behavior and stated that people are like machines and solely motivated by money. However, in all due respect to Taylor, he explicitly stated that his principles of scientific management were not for mental workers.
However, it happened. Applying a factory management style to highly intelligent professionals of the Creative Class that are specifically educated for their job and who love the challenges software development presents is problematic. According to the late Watts Humphries, the hierarchical management style associated with traditional software development practices does not work because people resent being treated like grunge. Taylor’s notion that people are like machines, solely motivated by money, has albeit unconsciously, contaminated software management. The results are burnt-out staff, deep developer-manager mistrust and Dilbert-style management. A survey by the Meta Group indicated that 71% of the 668 IT managers questioned said that IT staff burnout was a serious issue in their companies.
Burnout people are not productive people. OSEA applies four ways to increase staff productivity: team improvements, staff motivation and morale, employee loyalty, and management improvements. William James, of Harvard, in his study on motivation found that hourly employees could maintain their job and not be fired by working as low as 20 percent of their capability. The same study showed that hourly workers when motivated could work at 80 to 90 percent of their capability. It is not unreasonable to assume that if properly motivated, software developers could improve productivity by 30%.
Distributed team project management with its emphasis on leadership and staff motivation and morale will unleash the long dormant software developer productivity and maintain employee loyalty. Integrating the software teams with the business teams through the assignment of significant piece of user functionality like a subsystem will team improve productivity and system outputs. Distributed software development teams working in cohort with their user teammates can make local decisions at the point of action and control. This is in contrast to following the centralized hierarchical change process that requires staff wait in line for the project manager to make every simple decision.
Employee loyalty is very important because people are reservoirs of organizational and domain knowledge. Every time an experienced, valued member leaves, the organization reduces its productivity. However, because of the scientific management underpinnings,
IT employees remain under confident and dissatisfied. A survey finds that only 13 percent of surveyed IT professionals believe the economy is strengthening and only 11 percent are confident that more IT jobs exists. Yet, 32 percent of IT workers will likely look for a new job. Management training and programs design to increase staff motivation, morale, and employee loyalty will significantly increase productivity and increase staff retention. Publicly recognizing and rewarding achievers who do good work by providing advanced training, promotion planning, career development, skills assessment and training, and plum assignments will increase individual productivity.
However, the greatest impact is on CIO stability. Most software organizations CIOs are revolving doors. Studies show that Federal CIO change jobs every two years. This is about the same for many business CIOs. The results are Sisyphean in that software organizations are in a constant state of flux, change, turbulence, and chaos. By the time the organization adapts to the new CIO and absorbs her changes she leaves another comes with a new set of changes. The cycle of change, disorder, turbulence and chaos begins all over again.
There is more good news. Upcoming blogs will discuss how the OSEA can increase economic value and productivity, bring offshore jobs back home, reduce project failure, and meet schedules on time and within budget.
