The RAIN Philosophy

I. Overview

Sound methodologies are essential to companies who construct things or execute projects. Any organization that builds anything, be it cars, buildings, computers, or software systems, needs to have a means of going about the process. Simply put, a methodology is a proven way of doing things, predefined to make a project run smoothly and meet it’s objectives. There are numerous methodologies in the IT industry, each one being a reflection of the people that endorse it. Whatever methodology is employed, it must be adhered to by all team members. Without at least a basic methodology, the project may have somewhat unpredictable results, depending solely on the merit of the individual team members. With a very experienced team, this can still lead to a measure of success, but not by design – it really does leave a lot to chance.

II. Why Do We Need Another Methodology?

It is extremely rare for any IT department to use any one methodology exclusively and faithfully, even when they create their own. The general trend in the industry is to subscribe to one particular methodology and use it with a grain of salt. In this way, the methodology becomes seasoned in a way that the company is comfortable with, but in some situations, this seasoning never occurs and the methodology is (at least partially) ignored, and thus, loses it’s value.

Some of these IT methodologies require specialized training courses, or even special software in order to use them. Such proprietary systems are not conducive to new ideas, tending to constrict creative thought. If a methodology is not simple enough to understand without extremely specialized training, it is unrealistic to expect someone to use it to create a new business system unless they have significant experience and training in that particular discipline. In short, such methodologies are at best not easily accessible, and at worst, impractical and un-useable.

On the other hand, there are valuable principles buried in a great number of these methodologies. As such, it is a great advantage to be able to use the principles at work from several different methodologies, so that consultants can have many different techniques in their repertoire, rather than using parts of a particular methodology for some phases of a project and then using no structure at all in other phases where the chosen methodology is seen as inadequate or cumbersome.

The desire for a hybrid methodology that doesn’t leave gaps for project phases to be handled in a haphazard way is how and why this methodology came into being.

III. What is RAIN?

The RAIN methodology is based on a number of modern software development and business process philosophies. In the IT industry today, there are many methods and approaches employed to create change in business processes, or to conduct successful projects. While most of these methods can be, and are used with great success, there are recognized shortcomings inherent in each one. Our consultants have a well-rounded knowledge of various methodologies being touted in the industry today, and from that extensive knowledge, RAIN was developed to provide an experienced consultant with a solid framework in which to perform.

RAIN was specifically devised as a simple methodology that can be used in virtually any situation, a feature that is it’s greatest strength. Notably, RAIN does not attempt to define the project completely. Methodologies that attempt to do so typically cannot be used on projects that are not analogous to the one it was invented for, which leads to the habit of taking the methodology “with a grain of salt.” For maximum effect, RAIN was devised so that a consultant never has to deviate from any of its basic tenets, which are intentionally defined on a principle level, leaving the methodology flexible enough to be applied to any phase of any project, yet not so flexible that it fails either through being too elastic or through being so rigid that it isn’t used.

By defining processes on a principle level rather than in specific terms, we leave room for the techniques to be applied in various ways, and even in ways we never considered. While this often requires more of the individual team members in order to use RAIN successfully, it also releases the full potential of each member. Defining RAIN on a principle level rather than trying to consider “rules” for every step is also what makes it vastly transferable. RAIN is not meant to replace tools like UML or data modeling, or even flowcharts. When combined with the right tools and adequate experience, RAIN is an extremely powerful methodology that serves to remind each contributor that they have certain basic responsibilities and must continually monitor themselves against four basic objectives.

Rather than implying that RAIN is employable only by seasoned consultants, it must be noted that the methodology is appropriate for inexperienced team members as well, as it allows them to concentrate on simple concepts of project execution while working on the business problem. Under RAIN, inexperienced consultants can quickly realize their full potential, and their use of RAIN becomes increasingly effective as they themselves become seasoned consultants. For the inexperienced team member, the principle at play is that a methodology should not distract any contributor from the objectives of the project, but keep contributors focused on the business problem, not on the tools being used to solve it.

RAIN is language and platform independent. It is compatible with UML, RAD, cross-platform development using 4GL, and other tools. The methodology keeps contributors focused on correct priorities, continually repeating the basic processes necessary in all software projects: Recognize, Act, Invest, Nurture. Continual analysis is advantageous at all phases of a RAIN project.

IV. The four principles of RAIN

RAIN is an acronym that not only echoes its corporate heritage, it stands for the four principles to be followed in each phase of the project: recognize, act, invest, nurture. In addition to describing the four phases of a project at a high level, they also describe the principles to be followed within each phase. In other words, the principles nest within each step: “R” at the highest level has RAIN within it, as does “I”, and so on. At any level, each principle employs the same four tenets within it to complete that phase. Given a sizeable enough project, this nesting can be practically infinite. Each of the four principles is further described below. The descriptions infer the highest-level view of a project, but since they are principles, they also apply to each project phase, as noted.

Recognize: Do analysis. Engage in much more than that, however: comprehend the problem. Understand how the problem at hand is similar or dissimilar to other problems previously encountered. What have we learned in the past that helps us with this scenario? What do we need to learn to help us with this situation?

Act: Find a solution, not just a white paper. Having firmly grasped the problem, identify any measures that can be taken immediately to relieve strain on an organization or on individuals, or on an overtaxed system. Everybody wants short-term solutions, and there’s nothing inappropriate about providing them as long as the process doesn’t stop there. The Act step doesn’t end there, as a long-term solution must also be identified and described at this juncture.

Invest: Sooner or later you have to look at implementing the long-term solution you’ve devised. Acting immediately may remove some of the immediacy, but you will still need to invest resources in order to realize and implement a more permanent solution. This may involve time spent researching your clients, revising business practices, or simply doing a sizeable software development project to address the challenge within your existing business rules. The investment must inevitably be made by the organization, so trying to short-change or sidestep it will mean results unavoidably fall short of the expected or desired returns. In the investment phase, the resources applied may be financial or simply the allocation of knowledgeable staff or other resources to the project.

Nurture: It’s not over when it’s over. After the project is completed, you still need to take care of your business. This might be as simple as monitoring your email daily and engaging in on-going communication with the client, but you may also need to have staff looking after the inputs and outputs from the system, or you may need to arrange training and support. There may be ongoing maintenance or updates, especially if there is time-sensitive data involved. In nurturing, don’t be afraid to modify things you did in the investment phase. If things can be improved, you should be open to doing so. You can stop nurturing when you go out of business.

V. Where Does RAIN Start and End? Who Uses it?

The RAIN methodology is very simple, and applies to all levels. View it as a mantra: Recognize, Act, Invest, Nurture. These four things apply to all levels of a project, as well as separately to each individual level. When a company recognizes a problem, the need to act is immediate. Those are the first two steps. They may need to hire consultants, or perform work internally. Either solution is an investment. Once the solution is produced, it should be nurtured to make sure that it does not become obsolete. RAIN starts as soon as a problem is recognized, even if the problem is not yet fully described or its causes understood.

The analyst on the project also uses the mantra: Recognize the business function, Act by suggesting any changes that will be helpful immediately or to prepare for the long term solutions, Invest by planning and executing the long term solution for the project, and Nurture by making sure that the design works with the business and that it is understood in the following stages.

The project manager uses the mantra to ensure the project is administered effectively: Recognize the steps involved in implementing the long-term solution, Act by creating such things as a work plan and project timeline, Invest by allocating resources to each part of the plan, and Nurture by monitoring progress on the project and making necessary adjustments.

The developer on the project also uses the mantra: Recognize the solution, Act by implementing any short term fixes that can be made available to the business immediately, Invest by writing the bulk of the code for the long term solution, and Nurture the new product through the testing, quality assurance, and change control phases of the project to ensure a successfully implemented solution.

Testers can also employ the same approach: Recognize the system’s capabilities, Act by experimenting and trying a variety of possibilities, Invest by thoroughly testing all the functionality in as many permutations as possible, and Nurture through the bug fixing, change control, and any other revisions. The mantra can be used even further: on a large project, the leader of the test team may use it to create a testing plan, similar to the way the project manager did for the overall plan.

For a graphic designer creating a website or graphical layout, Recognize, Act, Invest, Nurture are still important – the context and the basic requirements have to be recognized first, then acted upon by creating distinctive ideas and samples or mocked-up layouts or proofs, invested in by doing the work to create the completed materials, and nurtured based on client or user feedback and any amended or added requirements.

Each task at each level can be performed effectively by following the same mantra. For the analyst writing a particular document, all four steps may be necessary to create a complete document. For the developer working on building a new screen, performing all four steps will yield a superior result for that screen.

VI. What Benefits are Realized by using RAIN?

RAIN encourages open interpretation and allows individuals to use it successfully in different ways, even in ways that were not originally intended…but that was the original goal. By operating at a principle level, rather than creating a strict way of running a project, RAIN creates a strict way of performing the task of running a project. And with RAIN, you don’t require specialized training if you are a developer that wants to be a project manager. You do, however need experience, which RAIN helps you gain quickly by encouraging creative ongoing thought and by both allowing and stimulating project members to realize their full potential.

Isn’t there Stuff Missing?

No, not really. We don’t have any need to re-invent the Gantt chart, or the E-R diagram. Or the Use Case model. These are all valid communication tools, but having lots of use case diagrams will not keep your project on track. Knowing what to do next will. You need to always keep in mind: Recognize, Act, Invest, Nurture. And if you get lost, don’t worry; you can’t be more than 3 steps away from the right one. It’s only slightly more complicated than “Wash, Rinse, Repeat.”

Footnotes:

This methodology was co-written with Scott Toderash in 2003 while we were partners in an IT consulting firm. I have edited only lightly for presentation here. Due to the document’s origin, it references software development in most of its examples, but the principles it describes are easily transferable to other types of projects. This document is one of two formats we produced, the other being an annotated version, which may at some point grow into a longer treatment of the subject. [back]

Interesting article. I’ve been reading business and management articles through a lens of social services lately because I have encountered so much poor management. The principles apply well. We don’t so much have a product as a service, but the process is equally as important, only ignored more in my realm.