Tuesday, June 08, 2004
Methodologies Part 2
The first client I was aware of that bought Immanent was a very large, well-known and wealthy financial services company in the midst of a major transformation effort. Please bear with the obfuscation, as we have to protect the innocent. The transformation had a hard deadline, and other than being a lot of tedious work with a lot of iterations, was actually a fairly straightforward project that was easy to understand after a couple of days of ramp-up. My particular part of the project was a small but critical part, but luckily we had an excellent team leader who knew the business domain (he had just completed just such a transformation effort) who also could do more than his share of the techie work. The problem arose with the PMO. Other than being just another project with incessant meetings (which led to the development of The Proprietor's Law), they had mandated the use of Immanent, as they felt it would add the controls and process to the project that it would need to pass muster with all of the scrutiny that would be attached to it. The problem lay in Immanent being a fairly inaccessible method, with the examples provided being very simplistic and not really applicable to a situation such as this, where the project was a hybrid of every usual model of an IT program.
So, enter the Immanent consultants. Oh, we all had the little binder, and the CD, but as I said, most of what was on there was inaccessible or irrelevant. And in comes Mr. Immanent Consultant, quite the expert at harrumphing (Mel Brooks nailed it in the scene in Blazing Saddles where Governor LePetomaine demands a harrumph from the yes-man). And Mr. Immanent Consultant came in demanding to know where our project charter was. Our team leader asked me to put my stuff on hold for a day or two and cobble up a project charter, a pretty odd requirement, since the letter of engagement and contract specified just exactly what we were tasked with, why we were tasked, and all of the stuff that ordinarily goes into that sort of thing. To me, a project charter is something that someone kicking a project off needs to do, not just for one mere component of the project (some clarification may be in order here, as what we were doing was indeed a full-blown project and not just a phase. However, what we were doing was the technical part of one part of the overall program). Mr. Immanent Consultant haughtily ordained that we could not proceed without the Project Charter, and a fully Immanentized project plan, resources leveled of course (as anyone who uses Microsoft Project for anything non-trivial can tell you, if you don't level the resources your project will be calculated to end sometime around the time Star Trek takes place). Mr. Immanent Consultant rejected several versions of the project charter and plan, most of which were short, to the point, and reasonably lucid. We pointed out repeatedly to no avail that there was plenty of definition around of what we were supposed to do, and we were already doing it with a simple logical process that actually followed Good Current Practices (the weasel term we used to avoid "best practices" which our risk managers advised us to avoid like the plague).
We eventually did get Mr. Immanent Consultant off our case (he really isn't a bad guy, and he did give us certain insight into the Esoteric Law that is Immanent that helped with subsequent, ahem, efforts). There was a realization at higher levels that project charters and the Powerpoints didn't help the effort, and the real things like analysis, design and operational docs were more important in this crash program than the management-speak tomes which land with thuds. There was some "escalario", as Tom Lehrer would say, involved....