A Method­ol­ogy Mantra: Rec­og­nize, Act, Invest, Nur­ture^[1]

I. Overview

Sound method­olo­gies are essen­tial to com­pa­nies who con­struct things or exe­cute projects. Any orga­ni­za­tion that builds any­thing, be it cars, build­ings, com­put­ers, or soft­ware sys­tems, needs to have a means of going about the process. Sim­ply put, a method­ol­ogy is a proven way of doing things, pre­de­fined to make a project run smoothly and meet it’s objec­tives. There are numer­ous method­olo­gies in the IT indus­try, each one being a reflec­tion of the peo­ple that endorse it. What­ever method­ol­ogy is employed, it must be adhered to by all team mem­bers. With­out at least a basic method­ol­ogy, the project may have some­what unpre­dictable results, depend­ing solely on the merit of the indi­vid­ual team mem­bers. With a very expe­ri­enced team, this can still lead to a mea­sure of suc­cess, 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 depart­ment to use any one method­ol­ogy exclu­sively and faith­fully, even when they cre­ate their own. The gen­eral trend in the indus­try is to sub­scribe to one par­tic­u­lar method­ol­ogy and use it with a grain of salt. In this way, the method­ol­ogy becomes sea­soned in a way that the com­pany is com­fort­able with, but in some sit­u­a­tions, this sea­son­ing never occurs and the method­ol­ogy is (at least par­tially) ignored, and thus, loses it’s value.

Some of these IT method­olo­gies require spe­cial­ized train­ing courses, or even spe­cial soft­ware in order to use them. Such pro­pri­etary sys­tems are not con­ducive to new ideas, tend­ing to con­strict cre­ative thought. If a method­ol­ogy is not sim­ple enough to under­stand with­out extremely spe­cial­ized train­ing, it is unre­al­is­tic to expect some­one to use it to cre­ate a new busi­ness sys­tem unless they have sig­nif­i­cant expe­ri­ence and train­ing in that par­tic­u­lar dis­ci­pline. In short, such method­olo­gies are at best not eas­ily acces­si­ble, and at worst, imprac­ti­cal and un-useable.

On the other hand, there are valu­able prin­ci­ples buried in a great num­ber of these method­olo­gies. As such, it is a great advan­tage to be able to use the prin­ci­ples at work from sev­eral dif­fer­ent method­olo­gies, so that con­sul­tants can have many dif­fer­ent tech­niques in their reper­toire, rather than using parts of a par­tic­u­lar method­ol­ogy for some phases of a project and then using no struc­ture at all in other phases where the cho­sen method­ol­ogy is seen as inad­e­quate or cumbersome.

The desire for a hybrid method­ol­ogy that doesn’t leave gaps for project phases to be han­dled in a hap­haz­ard way is how and why this method­ol­ogy came into being.

III. What is RAIN?

The RAIN method­ol­ogy is based on a num­ber of mod­ern soft­ware devel­op­ment and busi­ness process philoso­phies. In the IT indus­try today, there are many meth­ods and approaches employed to cre­ate change in busi­ness processes, or to con­duct suc­cess­ful projects. While most of these meth­ods can be, and are used with great suc­cess, there are rec­og­nized short­com­ings inher­ent in each one. Our con­sul­tants have a well-rounded knowl­edge of var­i­ous method­olo­gies being touted in the indus­try today, and from that exten­sive knowl­edge, RAIN was devel­oped to pro­vide an expe­ri­enced con­sul­tant with a solid frame­work in which to perform.

RAIN was specif­i­cally devised as a sim­ple method­ol­ogy that can be used in vir­tu­ally any sit­u­a­tion, a fea­ture that is it’s great­est strength. Notably, RAIN does not attempt to define the project com­pletely. Method­olo­gies that attempt to do so typ­i­cally can­not be used on projects that are not anal­o­gous to the one it was invented for, which leads to the habit of tak­ing the method­ol­ogy “with a grain of salt.” For max­i­mum effect, RAIN was devised so that a con­sul­tant never has to devi­ate from any of its basic tenets, which are inten­tion­ally defined on a prin­ci­ple level, leav­ing the method­ol­ogy flex­i­ble enough to be applied to any phase of any project, yet not so flex­i­ble that it fails either through being too elas­tic or through being so rigid that it isn’t used.

By defin­ing processes on a prin­ci­ple level rather than in spe­cific terms, we leave room for the tech­niques to be applied in var­i­ous ways, and even in ways we never con­sid­ered. While this often requires more of the indi­vid­ual team mem­bers in order to use RAIN suc­cess­fully, it also releases the full poten­tial of each mem­ber. Defin­ing RAIN on a prin­ci­ple level rather than try­ing to con­sider “rules” for every step is also what makes it vastly trans­fer­able. RAIN is not meant to replace tools like UML or data mod­el­ing, or even flow­charts. When com­bined with the right tools and ade­quate expe­ri­ence, RAIN is an extremely pow­er­ful method­ol­ogy that serves to remind each con­trib­u­tor that they have cer­tain basic respon­si­bil­i­ties and must con­tin­u­ally mon­i­tor them­selves against four basic objectives.

Rather than imply­ing that RAIN is employ­able only by sea­soned con­sul­tants, it must be noted that the method­ol­ogy is appro­pri­ate for inex­pe­ri­enced team mem­bers as well, as it allows them to con­cen­trate on sim­ple con­cepts of project exe­cu­tion while work­ing on the busi­ness prob­lem. Under RAIN, inex­pe­ri­enced con­sul­tants can quickly real­ize their full poten­tial, and their use of RAIN becomes increas­ingly effec­tive as they them­selves become sea­soned con­sul­tants. For the inex­pe­ri­enced team mem­ber, the prin­ci­ple at play is that a method­ol­ogy should not dis­tract any con­trib­u­tor from the objec­tives of the project, but keep con­trib­u­tors focused on the busi­ness prob­lem, not on the tools being used to solve it.

RAIN is lan­guage and plat­form inde­pen­dent. It is com­pat­i­ble with UML, RAD, cross-platform devel­op­ment using 4GL, and other tools. The method­ol­ogy keeps con­trib­u­tors focused on cor­rect pri­or­i­ties, con­tin­u­ally repeat­ing the basic processes nec­es­sary in all soft­ware projects: Rec­og­nize, Act, Invest, Nur­ture. Con­tin­ual analy­sis is advan­ta­geous at all phases of a RAIN project.

IV. The four prin­ci­ples of RAIN

RAIN is an acronym that not only echoes its cor­po­rate her­itage, it stands for the four prin­ci­ples to be fol­lowed in each phase of the project: rec­og­nize, act, invest, nur­ture. In addi­tion to describ­ing the four phases of a project at a high level, they also describe the prin­ci­ples to be fol­lowed within each phase. In other words, the prin­ci­ples nest within each step: “R” at the high­est level has RAIN within it, as does “I”, and so on. At any level, each prin­ci­ple employs the same four tenets within it to com­plete that phase. Given a size­able enough project, this nest­ing can be prac­ti­cally infi­nite. Each of the four prin­ci­ples is fur­ther described below. The descrip­tions infer the highest-level view of a project, but since they are prin­ci­ples, they also apply to each project phase, as noted.

Rec­og­nize: Do analy­sis. Engage in much more than that, how­ever: com­pre­hend the prob­lem. Under­stand how the prob­lem at hand is sim­i­lar or dis­sim­i­lar to other prob­lems pre­vi­ously encoun­tered. What have we learned in the past that helps us with this sce­nario? What do we need to learn to help us with this situation?

Act: Find a solu­tion, not just a white paper. Hav­ing firmly grasped the prob­lem, iden­tify any mea­sures that can be taken imme­di­ately to relieve strain on an orga­ni­za­tion or on indi­vid­u­als, or on an over­taxed sys­tem. Every­body wants short-term solu­tions, and there’s noth­ing inap­pro­pri­ate about pro­vid­ing them as long as the process doesn’t stop there. The Act step doesn’t end there, as a long-term solu­tion must also be iden­ti­fied and described at this juncture.

Invest: Sooner or later you have to look at imple­ment­ing the long-term solu­tion you’ve devised. Act­ing imme­di­ately may remove some of the imme­di­acy, but you will still need to invest resources in order to real­ize and imple­ment a more per­ma­nent solu­tion. This may involve time spent research­ing your clients, revis­ing busi­ness prac­tices, or sim­ply doing a size­able soft­ware devel­op­ment project to address the chal­lenge within your exist­ing busi­ness rules. The invest­ment must inevitably be made by the orga­ni­za­tion, so try­ing to short-change or side­step it will mean results unavoid­ably fall short of the expected or desired returns. In the invest­ment phase, the resources applied may be finan­cial or sim­ply the allo­ca­tion of knowl­edge­able staff or other resources to the project.

Nur­ture: It’s not over when it’s over. After the project is com­pleted, you still need to take care of your busi­ness. This might be as sim­ple as mon­i­tor­ing your email daily and engag­ing in on-going com­mu­ni­ca­tion with the client, but you may also need to have staff look­ing after the inputs and out­puts from the sys­tem, or you may need to arrange train­ing and sup­port. There may be ongo­ing main­te­nance or updates, espe­cially if there is time-sensitive data involved. In nur­tur­ing, don’t be afraid to mod­ify things you did in the invest­ment phase. If things can be improved, you should be open to doing so. You can stop nur­tur­ing when you go out of business.

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

The RAIN method­ol­ogy is very sim­ple, and applies to all lev­els. View it as a mantra: Rec­og­nize, Act, Invest, Nur­ture. These four things apply to all lev­els of a project, as well as sep­a­rately to each indi­vid­ual level. When a com­pany rec­og­nizes a prob­lem, the need to act is imme­di­ate. Those are the first two steps. They may need to hire con­sul­tants, or per­form work inter­nally. Either solu­tion is an invest­ment. Once the solu­tion is pro­duced, it should be nur­tured to make sure that it does not become obso­lete. RAIN starts as soon as a prob­lem is rec­og­nized, even if the prob­lem is not yet fully described or its causes understood.

The ana­lyst on the project also uses the mantra: Rec­og­nize the busi­ness func­tion, Act by sug­gest­ing any changes that will be help­ful imme­di­ately or to pre­pare for the long term solu­tions, Invest by plan­ning and exe­cut­ing the long term solu­tion for the project, and Nur­ture by mak­ing sure that the design works with the busi­ness and that it is under­stood in the fol­low­ing stages.

The project man­ager uses the mantra to ensure the project is admin­is­tered effec­tively: Rec­og­nize the steps involved in imple­ment­ing the long-term solu­tion, Act by cre­at­ing such things as a work plan and project time­line, Invest by allo­cat­ing resources to each part of the plan, and Nur­ture by mon­i­tor­ing progress on the project and mak­ing nec­es­sary adjustments.

The devel­oper on the project also uses the mantra: Rec­og­nize the solu­tion, Act by imple­ment­ing any short term fixes that can be made avail­able to the busi­ness imme­di­ately, Invest by writ­ing the bulk of the code for the long term solu­tion, and Nur­ture the new prod­uct through the test­ing, qual­ity assur­ance, and change con­trol phases of the project to ensure a suc­cess­fully imple­mented solution.

Testers can also employ the same approach: Rec­og­nize the system’s capa­bil­i­ties, Act by exper­i­ment­ing and try­ing a vari­ety of pos­si­bil­i­ties, Invest by thor­oughly test­ing all the func­tion­al­ity in as many per­mu­ta­tions as pos­si­ble, and Nur­ture through the bug fix­ing, change con­trol, and any other revi­sions. The mantra can be used even fur­ther: on a large project, the leader of the test team may use it to cre­ate a test­ing plan, sim­i­lar to the way the project man­ager did for the over­all plan.

For a graphic designer cre­at­ing a web­site or graph­i­cal lay­out, Rec­og­nize, Act, Invest, Nur­ture are still impor­tant – the con­text and the basic require­ments have to be rec­og­nized first, then acted upon by cre­at­ing dis­tinc­tive ideas and sam­ples or mocked-up lay­outs or proofs, invested in by doing the work to cre­ate the com­pleted mate­ri­als, and nur­tured based on client or user feed­back and any amended or added requirements.

Each task at each level can be per­formed effec­tively by fol­low­ing the same mantra. For the ana­lyst writ­ing a par­tic­u­lar doc­u­ment, all four steps may be nec­es­sary to cre­ate a com­plete doc­u­ment. For the devel­oper work­ing on build­ing a new screen, per­form­ing all four steps will yield a supe­rior result for that screen.

VI. What Ben­e­fits are Real­ized by using RAIN?

RAIN encour­ages open inter­pre­ta­tion and allows indi­vid­u­als to use it suc­cess­fully in dif­fer­ent ways, even in ways that were not orig­i­nally intended…but that was the orig­i­nal goal. By oper­at­ing at a prin­ci­ple level, rather than cre­at­ing a strict way of run­ning a project, RAIN cre­ates a strict way of per­form­ing the task of run­ning a project. And with RAIN, you don’t require spe­cial­ized train­ing if you are a devel­oper that wants to be a project man­ager. You do, how­ever need expe­ri­ence, which RAIN helps you gain quickly by encour­ag­ing cre­ative ongo­ing thought and by both allow­ing and stim­u­lat­ing project mem­bers to real­ize 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 dia­gram. Or the Use Case model. These are all valid com­mu­ni­ca­tion tools, but hav­ing lots of use case dia­grams will not keep your project on track. Know­ing what to do next will. You need to always keep in mind: Rec­og­nize, Act, Invest, Nur­ture. 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 com­pli­cated than “Wash, Rinse, Repeat.”