Lean Project Management

Effective Software Development

Why do projects miss their deadlines and exceed their budgets? Are we poor planners or are we poor managers? One of the basic problems that complicates project estimating, scheduling, and management is the failure to manage the creativity.

The manufacturing and construction industries recognized this problem a long time ago. One hundred years ago, they employed highly skilled craftsmen and each product was a reflection of the design and creativity of the individual. Today, the creative process is the responsibility of engineers and architects. The job of plumbers, electricians, and manufacturing line workers is to build the product according to the design.

Many IT projects allow creativity to be distributed across the life-cycle of a project. Today’s object-oriented development languages provide significant options for artistic and functional creativity. The problem: How do you know when someone will finish being creative? These activities are impossible to estimate. Creative choices by individuals may result in a lack of consistency which confuses users. Creative re-work also adds costs and negatively impacts quality because the frequent changes are not adequately tested.

Common Development Practices

1. IT organizations develop Software in response to a unique set of requirements similar to a fabrication plant. They employ skilled craftsmen who utilize their creative skills to develop software that is customized for the stated requirements. This approach is similar to the use of craftsman by the manufacturing industry prior to the 20th century (with similar results). Each product is unique and quality and efficiency are the responsibility of the individual craftsman and difficult to measure.

2. Functionality is based on the unique requirements as defined by the requester. The quality and efficiency of the design and the final product is the direct result of the creativity and skill level of the individual developers. As a result, quality and cost can be unpredictable.

3. The effort (and the cost) for designing and developing these unique “one off” applications is significant. As a result, new applications are rarely authorized and we continue to operate and maintain older legacy applications. Support costs are also higher because the resulting applications require special knowledge to operate and support because they are all uniquely different in their basic design.

4. Collecting metrics to facilitate estimating and scheduling is difficult. Creative activities are difficult to measure and metrics generation requires additional effort that is typically resisted. Even if metrics are collected, they are useful in defining and measuring quality but the existence of metrics to not ensure quality.

5. Repeatable processes are marginally useful in defining and managing creative fabrication activities. They are very useful in managing repeatable assembly activities.

6. Development tools change frequently. The decision to utilize a new tool is very often made by a developer without serious consideration for the available knowledge base and future support challenges.

7. Most of these new Object-Oriented languages are based on low-level rudimentary languages like C++ and Basic. They facilitate code re-usability at the object level (e.g. drop down boxes) but they hinder re-usability at the functional level. In the past, we could develop an online interactive program that updated a database and clone this program to develop other similar functions. This level of re-usability is much more difficult with Object Oriented languages.

8. These new Object Oriented Languages are much more difficult to learn than their predecessors. Inexperienced developers are more likely to have learned the newer languages but they do not have the design skills required to develop new applications. IT organizations do not train their experienced developers on newer technologies. As a result, the average skill level available for newer technologies is not adequate for developing complex applications.

The Solution: Manage Creativity and Plan Re-Usability

“Object Oriented” languages claim to provide re-usability. Unfortunately, their re-usable components are low-level objects. They provide re-usable functions for creating a drop-down list but do not provide a re-usable function for updating information about people.
IT needs to be more proactive in developing and utilizing re-usable components. We also need to manage and control creative activities that are difficult to estimate and can have significant impacts on the schedule, quality, risk, and cost of a project. The following recommendations apply to each technology area:

1. Create re-usable specifications and functions. Most systems maintain data about people, places, things, and processes. When designing screens and databases to maintain this type of information, choose design options that provide the greatest potential for re-use in future applications. Most applications track people and organizations. Unfortunately, these functions were designed to be unique to each application and are not re-usable across applications. Re-usability should be a high priority design consideration.

2. Use bench resources and trainees to create/enhance re-usable modules. Gradually, an inventory of high quality modules will be available for each technology area that will facilitate future development.

3. Maintain an inventory of re-usable modules. Modules cannot be re-used if developers are not aware of their existence. This inventory should also include re-usable specifications and documentation.

4. Define requirements and functional specifications based on existing re-usable functions. This facilitates the rapid demonstration of the solution and maximizes the possibility for re-using existing functionality. By re-using specs and modules, we will reduce the cost of designing and developing these functions for every application.

The recommendations I am describing are old solutions. We have discarded these proven solutions because newer Object Oriented technologies have claimed to be re-usable but they only provide re-usability at the individual object level (e.g. drop down box). Re-using functional components requires a proactive effort on the part of IT organizations but the benefits can be significant. If we implement these recommendations, we will be following the example of the manufacturing industry by assembling components to build systems and reducing dependence on the creative skills of craftsmen.

Related Articles

Back to top button

We use cookies on our website

We use cookies to give you the best user experience. Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.