Implementing a Methodology

"The least expensive decision will be the price of the package."
- Bryce's Law

INTRODUCTION

The use of organized methodologies for the development of systems and software have been around for 35 years ("PRIDE" was the first in 1971). Today, there are dozens, if not hundreds, of methodologies available for use. Many are simply a variation on the traditional theme of: feasibility study, external design, internal design, program, test, install, review. Others take an iterative approach to development. Regardless of what methodology you elect to use, whether "PRIDE" or Brand X, there are some serious implementation considerations to ponder and it would be foolish not to look before you leap into one.

First, recognize you will spend more time and money implementing a methodology than you will on its purchase. This is because methodologies radically affect the corporate culture, at least in the Information Technology (IT) department. It means breaking old work habits and introducing new ones. It also represents standardization which developers often resist. Methodologies represents uniformity in development practices and deliverables with the intent of turning a heterogeneous development environment into one that is homogeneous. By doing so, methodologies seek to produce consistent and predictable results. They also greatly facilitate teamwork as opposed to rugged individualism. As such, their impact on human behavior should not be underestimated.

SELECTION

Not all methodologies are created equally. Having been involved in this industry for over 30 years, we have had the opportunity to see many different interpretations of the methodology concept. Some are rather simple, others are overtly complex (which we like to refer to as "the dance of the fairies"). When studying any methodology, consideration should be given to the following areas:

* Conceptual Foundation - defining the intent of the product and the rationale for construction of the methodology. First, what is it intended to produce? Total systems or just the software portions? What about the data base? Is this a universally applicable approach or tailored for a specific type of application, e.g., SOA, real-time, etc. This will help define the scope of the methodology and who it is intended to use it. Next, study the underlying concepts and philosophies from which the methodology is based. For example, "PRIDE" establishes an analogy between engineering/manufacturing concepts to the development of systems. This may be fine for those people who understand such concepts, but difficult for others to assimilate. Regardless, the concepts and philosophies must be understood and agreed upon. Further, the terminology used in the methodology must also be well defined and consistently applied throughout it, thereby providing a uniform vocabulary for developers (and end-users) to communicate. Ideally, a glossary of terms is provided with the methodology.

* Methodology Structure and Navigation - defining the standard work breakdown structure (WBS) such as phases, activities, and tasks, along with their dependencies (comes from/goes to). In terms of the WBS, consider the level of detail provided and the rationale for the various work steps. For example, each should be designed to produce a tangible result in order to substantiate completeness. If it doesn't, it may very well be a waste of time. Also, consideration should be given to what work steps must be performed sequentially and which can be performed in parallel. This has Project Management implications. Laced throughout the methodology should be review points to study progress, make revisions, or make stop/go decisions.

* Deliverables - defining what is to be produced from executing the various work steps. This can take many forms, such as reports, program code, data base structures, test data, etc. For each deliverable, particularly reports, there should be defined acceptance criteria which provides the means to analyze it for completeness.

The methodology must clearly define Who is to perform What, When, Where, Why and How (5W+H) thereby delineating the responsibilities for executing the various parts of the methodology. Assuming this is understood and agreed upon, the next step is to consider how the methodology will impact your organization. Will it be a radical departure from the current way your company operates or will it be relatively easy to assimilate in your organization? The greater the change, the greater your implementation costs will be. Then again, maybe your organization needs a radical shakeup.

STRATEGIES

Because a methodology plays a dramatic role in the corporate culture, it is not installed in the same manner as computer hardware or software. We have seen many approaches to the implementation of methodologies over the years; some successful, some disastrous. The disastrous implementations are those where a "Dictator" approach is taken and the methodology is jammed down everyone's throat. This will only work as long as the dictator remains in power and is typically abandoned shortly thereafter. The more successful implementations have been those where the responsibility for the methodology is shouldered by several key people in the organization, thereby giving the appearance that the methodology is the will of the company and not just one individual.

STEP 1 - ESTABLISH A PROJECT

The first step in installing a methodology is to establish a project for this purpose. This can be done using a Project Management system (either manually implemented or computer assisted) which materially assists in keeping the project on schedule and within costs.

Key to the startup of the project is the appointment of a Methodology Coordinator who will act as the Project Manager for the implementation of the product. Considerable thought should go into the selection of this person. The Coordinator should be respected by the development staff as well as management; should work well with people, but more importantly, must be results oriented.

STEP 2 - ESTABLISH SUPPORT TEAM

A Support Team is assembled who will be assigned tasks in the project. One of the principal reasons for forming a Support Team is to share the responsibility for implementing the methodology throughout the company. Again, this conveys the image that the methodology is the will of the company, not just a single person.

Selecting members for the Support Team is critical. During the implementation process, they will have high visibility and will become the in-house experts in the use of the methodology. As such, the people selected must be able to speak with authority and command respect. Those typically involved in the implementation of a methodology include:

* Methodology Coordinator - the person selected for this key assignment must have a management background.

* Enterprise Resource Manager - this will be the person primarily concerned with business planning.

* Systems Resource Manager - this will be the person primarily concerned with systems and software development responsibilities.

* Data Resource Manager - this will be the person primarily concerned with data base matters.

* Quality Assurance Manager - the person who will be concerned with the development and enforcement of all IT related standards.

* Training Coordinator - the person who will be concerned with providing educational services for the company.

* Project Administrator - the person primarily responsible for installing and administering the Project Management system.

* Technical Librarian - the person responsible for maintaining all IT related documentation, e.g., phase deliverables, and project documentation.

This does not mean implementing a methodology requires enormous resources. Depending on the type of methodology to be installed, certain people may not be involved. Also, some members of the team may share responsibilities (such as Project Administration/Technical Librarian). Participation in the support team is not necessarily a full time job especially if the work is evenly distributed between members of the team.

It is important that a unique mix of both managers and staff from various areas participate in the Support Team in order to give the project effectiveness, credibility, and balance. Junior people may be useful for establishing the mechanics of the product, but it will require managers to set standards, promote the use of the methodologies, and handle political issues.

One of the first steps by the Support Team is to become conversant in the methodology themselves. This can be accomplished by reviewing the methodology documentation and by attending pertinent training courses.

STEP 3 - DEVISE STRATEGY

In essence, the Support Team will be fulfilling the role of "Industrial Engineering" as found in a manufacturing facility. Under this scenario, they will be studying the methodology and determine:

* Supplemental tools and techniques to be used throughout the methodologies. This includes such things as development tools, programming standards, Repositories, and Project Management aids.

* The necessary management infrastructure to support the methodology. This specifically includes the development of a Quality Assurance organization which includes the Technical Library and Project Administration functions.

* Training requirements - for developers, support functions, as well as management and end-users.

Perhaps the biggest decision to be made at this point is an implementation strategy whereby the company either installs the methodology all at once or takes an evolutionary approach where key projects are selected for the initial use of the methodology (a sort of "snowball" effect). The latter approach is probably the most effective for getting started.

STEP 4 - INITIATE PLAN

During this stage, the Support Team will implement the necessary support infrastructure, execute their training plan, and begin to use the methodology. During the first few projects, pay particular attention to how the methodology is used and look for problem areas. Here, the Support Team becomes a SWAT team to correct problem areas as quickly as possible. The intent is to gain momentum and perfect the use of the product (which will become an ongoing goal).

After the methodology is installed, encourage forums where the mechanics of the methodology are discussed with the staff. Such forums promote self-improvement. Although this can be performed using such things as Internet blogs and discussion groups, face-to-face meetings are more effective to clarify points (perhaps after normal working hours).

CONCLUSION

A methodology is an important part of an overall quality assurance program whereby standard practices are initiated in order to produce consistent and measurable work products. Ultimately, it represents discipline, organization, and accountability which the development staff will realize almost immediately and, as such, will either embrace or resist it. Because it represents a change to the current operating environment, you should expect developers to resist it as much as new users resist the introduction of new technology in their business units. Consequently, don't expect a methodology to install itself. Always remember that it is one thing to enact legislation, quite another to enforce it. Without follow-up and enforcement, use of the methodology will be spotty at best. You will know when a methodology has been successfully implemented when it has become an inherent part of the corporate culture; that developers communicate and act on a common level, that consistent work products are produced; that the staff behaves more as a team as opposed to a group of individuals, and; that it is no longer the Brand X Methodology, but rather it is "Our" Methodology.