June 25, 2007

"IMPLEMENTING A METHODOLOGY"

The use of organized methodologies for the development of systems and software have been around for 36 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.

OUR BRYCE'S LAW OF THE WEEK therefore is... "The least expensive decision will be the price of the package."

"PRIDE" METHODOLOGIES FOR IRM

Friends, the "PRIDE" Methodologies for Information Resource Management (IRM) is a common sense solution for Enterprise Engineering, Systems Engineering, Data Base Engineering, and Project Management. The methodologies include defined work breakdown structures, deliverables, and review points that promote quality and the production of industrial-strength information systems. Building information resources is a science, not an art form. Our methodologies clearly explain the concepts that govern them, which remarkably, is derived from engineering/manufacturing practices. Now you can get these acclaimed methodologies for free at our corporate web site at: http://www.phmainstreet.com/mba/pride/

MY "PET PEEVE OF THE WEEK" IS "VERIZON"

We were recently visited at our office by a representative of telephone giant Verizon who wanted to review our current plan and see if she could save us some money. Basically she recommended we consolidate our telephone lines, long distance and Internet connections into a single reduced monthly fee. It sounded good and we went along with it. When our next bill came, we discovered that our fees had actually gone up as opposed to down (it almost doubled). "Strike one."

Obviously irritated with the bill, we wanted to find out exactly what was going on and endeavored to contact Verizon about our billing. Ever try to call Verizon lately? They have taken "Voice Mail Jail" to a whole new level. You are asked a series of questions by a preprogrammed voice that theoretically is to expedite your problem and take care of you. Wrong. No matter how we tried to work within their voice mail system we were never able to get the answers we were looking for. Even worse, our frustration level arose to a new level as we were never allowed to talk to a human being about our problem. "Strike two."

Whoever thought Verizon's voice mail system improved customer service should be taken out and horse whipped. Actually, I got the impression there isn't a breathing person at Verizon; that everything is being run by computers and the executives are lying on a beach somewhere in the Caribbean. I guess its not a bad gig if you can set your company up this way and you really do not care about customer service.

I'm just wondering how many other customers they have been able to alienate or are we the only ones left using Verizon? We better get this problem resolved soon or it will be "Strike Three" and they're out of here.

Such is my Pet Peeve of the Week.

"BRYCE'S IS RIGHT!"

Folks, a couple of years ago I started to include my "Pet Peeve of the Week" in these "Management Visions" podcasts. They have become so popular that I now syndicate them through the Internet and they are available for republication in other media. To this end, I have created a separate web page for my writings which you can find at phmainstreet.com Look for the section, "The Bryce is Right!" Hope you enjoy them.

AND FINALLY...

An N.A. in Tampa wrote me regarding my recent "Pet Peeve" on "The Moral Minority." He writes:

"Wow, this was very good. The United States will fall—that is inevitable. We’ll be like ancient Rome: we won’t be conquered, we’ll disintegrate from within. You can already see the fissures. I don’t think it’ll happen in my lifetime. I predict it will happen by the turn of the next century."

Thanks for your comments.

Again, thanks for your e-mail. Keep those cards and letters coming.

MBA is an international management consulting firm specializing in Information Resource Management. We offer training, consulting, and writing services in the areas of Enterprise Engineering, Systems Engineering, Data Base Engineering, Project Management, Methodologies and Repositories. For information, call us at 727/786-4567. For a complete listing of my essays, see the "PRIDE" Special Subject Bulletins section of our corporate web site.

Our corporate web page is at:

http://phmainstreet.com/mba/

Management Visions is a presentation of M. Bryce & Associates, a division of M&JB Investment Company of Palm Harbor, Florida, USA. The program is produced on a weekly basis and updated on Sundays. It is available in versions for RealPlayer, Microsoft Media Player, and MP3 suitable for Podcasting. See our web site for details. You'll find our broadcast listed in several Podcast and Internet Search engines, as well as Apples' iTunes.

If you have any questions or would like to be placed on our e-mailing list to receive notification of future broadcasts, please e-mail it to timb001@phmainstreet.com

For a copy of past broadcasts, please contact me directly.

We accept MP3 files with your voice for possible inclusion in the broadcast.

There is no charge for adding a link to "Management Visions" on your web page, for details and HTML code, see the "Management Visions" web site.

Management Visions accepts advertising. For rates, please contact yours truly directly.

Copyright © 2007 by M&JB Investment Company of Palm Harbor, Florida, USA. All rights reserved. "PRIDE" is the registered trademark of M&JB Investment Company.

This is Tim Bryce reporting.

Since 1971: "Software for the finest computer - the Mind."

END