“The cheapest decision is the price of the package.”
– Bryce’s law
The use of organized methodologies for system and software development has 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, testing, installation, assessment. Others have an iterative approach to development. Regardless of which methodology you choose to use, whether it is “PRIDE” or Brand X, there are some serious implementation considerations to think about and it would be foolish not to look before jumping into it.
First, acknowledge that you will spend more time and money implementing a methodology than purchasing it. This is because methodologies radically influence corporate culture, at least in the Information Technology (IT) department. It means breaking old work habits and introducing new ones. It also stands for standardization that developers often resist. Methodologies stand for uniformity in development practices and results with the intention of turning a heterogeneous development environment into one that is homogeneous. By doing this, methodologies strive for 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.
Not all methodologies are created equal. After being involved in this industry for over 30 years, we have had the opportunity to see many different interpretations of the methodology concept. Some are quite simple, others are openly complex (which we like to refer to “the dance of the fairies”). When studying a methodology, the following areas should be taken into account:
* Conceptual basis – defining the intention of the product and the rationale for the construction of the methodology. First, what is it intended to produce? Total systems or only the software parts? What about the database? Is this a universally applicable approach or tailored for a specific type of application, for example SOA, real-time, etc. This will help define the scope of the methodology and for whom it is intended. Then study the underlying concepts and philosophies on which the methodology is based. For example, “PRIDE” establishes an analogy between engineering / manufacturing concepts and system development. This can be fine for people who understand such concepts, but difficult for others to assimilate. Either way, the concepts and philosophies need to be understood and agreed upon. Furthermore, the terminology used in the methodology must also be well defined and applied consistently throughout, allowing developers (and end users) to use a uniform vocabulary to communicate. Ideally, a glossary is provided with the methodology.
* Methodology Structure and navigation – defining the standard work breakdown structure (WBS) such as phases, activities and tasks, together with their dependencies (comes from / goes to). In terms of the WBS, consider the level of detail provided and the rationale for the different work steps. For example, each must be designed to produce a tangible result to support completeness. If not, it might be a waste of time. It should also be considered which work steps should be performed sequentially and which can be performed in parallel. This has consequences for Project Management. Strung through the whole methodology, assessment points should be to study progress, make revisions, or make stop / go decisions.
* Products to be delivered – define what should be produced by performing the different work steps. This can take many forms, such as reports, program code, database structures, test data, etc. For each product, especially reports, there must be acceptance criteria that provide the means to analyze completeness.
The methodology should clearly define who should do what, when, where, why and how (5W + H), defining the responsibilities for carrying out the different parts of the methodology. Assuming this is understood and agreed upon, the next step is to consider how the methodology will affect your organization. Is it going to deviate radically from the current way of working of your company or is it relatively easy to assimilate in your organization? The larger the change, the higher the implementation costs. On the other hand, your organization may need a radical upheaval.
Because a methodology plays a dramatic role in the corporate culture, it is not installed in the same way as computer hardware or software. We have seen many approaches to implementing methodologies over the years; some successful, some disastrous. The disastrous implementations are those where a “dictator” approach is followed and the methodology is blocked by everyone’s throat. This only works as long as the dictator remains in power and is left shortly after. The more successful implementations were those where the responsibility for the methodology is borne by different key figures in the organization, making it seem as if the methodology is the will of the company and not just one individual.
STEP 1 – CREATE A PROJECT
The first step in installing a methodology is to set up a project for this. This can be done using a project management system (manually implemented or computer-aided) that materially helps keep the project on schedule and within cost.
The key to starting the project is the appointment of a methodology coordinator who will act as the project manager for the implementation of the product. Much attention should be paid to the selection of this person. The coordinator must be respected by both development personnel and management; must work well with people, but more importantly, must be result-oriented.
STEP 2 – SET UP A SUPPORT TEAM
A support team is set up to be assigned tasks in the project. One of the main reasons to form a Support Team is to share responsibility for implementing the methodology across 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 have high visibility and become the internal experts in the use of the methodology. As such, the selected people should be able to speak with authority and command respect. Those who are usually involved in the implementation of a methodology are:
* Methodology Coordinator – the person selected for this key assignment must have a management background.
* Enterprise Resource Manager – this will be the person who is mainly concerned with business planning.
* Systems Resource Manager – this will be the person who is primarily responsible for systems and software development responsibilities.
* Data Resource Manager – this will be the person who mainly deals with database matters.
* Quality Assurance Manager – the person engaged in the development and enforcement of all IT related standards.
* Training Coordinator – the person who is engaged in providing educational services for the company.
* Project manager – the person primarily responsible for installing and managing the project management system.
* Technical Librarian – the person responsible for maintaining all IT related documentation, for example phase deliverables and project documentation.
This does not mean that implementing a methodology requires enormous resources. Depending on the type of methodology to be installed, certain people may not be involved. Some team members may also 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 divided equally among the members of the team.
It is important that a unique mix of both managers and employees from different areas participate in the support team to give the project effectiveness, credibility and balance. Junior people can be helpful in establishing the mechanics of the product, but it requires managers to set standards, promote the use of methodologies and address political issues.
One of the first steps of the support team is to become familiar with the methodology yourself. This can be achieved by reviewing the documentation of the methodology and following relevant training courses.
STEP 3 – DEVISE STRATEGY
In essence, the support team fulfills the role of “Industrial Engineering” as found in a production facility. In this scenario, they will study and determine the methodology:
* Additional tools and techniques to be used in all methodologies. This includes things like development tools, programming standards, repositories, and project management tools.
* The necessary management infrastructure to support the methodology. This includes in particular the development of a quality assurance organization that covers the functions of the technical library and project administration.
* Training requirements – for developers, support functions, as well as management and end users.
Perhaps the biggest decision to make right now is an implementation strategy where the company installs the methodology all at once or adopts an evolutionary approach that selects key projects for the first use of the methodology (a kind of “snowball effect”). This last approach is probably the most effective to get started.
STEP 4 – INITIATION PLAN
During this phase, the support team will implement the necessary support infrastructure, implement their training plan and use the methodology. During the first few projects, pay particular attention to using the methodology and look for problem areas. Here the support team becomes a SWAT team to resolve problem areas as quickly as possible. The aim 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 staff. Such forums promote self-improvement. While this can be done with things like internet blogs and discussion groups, face-to-face meetings are more effective in clarifying points (perhaps after normal working hours).
A methodology is an important part of an overall quality assurance program that initiates standard practices to produce consistent and measurable work products. Ultimately it stands for discipline, organization and responsibility that the development staff will implement almost immediately and as such will embrace or resist. Since it means a change in the current work environment, you can expect developers to resist, just as new users resist introducing new technology into their businesses. Therefore, don’t expect a methodology to install itself. Always remember that it is one thing to enact legislation, and another to enforce it. Without follow-up and enforcement, using the methodology will be spotty at best. You know when a methodology has been successfully implemented when it has become an inherent part of the corporate culture; that developers communicate and act at a common level, that consistent work products are produced; that the staff behaves more as a team than as a group of individuals, and; that it is no longer the Brand X Methodology, but rather “Our” Methodology.