Monday, July 19, 2004


Methodologies Part 4

Way back in Part 1, we were introduced to Immanent, which of course was later replaced with Immanent Mark 2, which has now been subsumed and sunsetted with the preferred standard now being Respect Employer's Large Business Unified Method (hereinafter referred to as RELBUM). RELBUM actually offers several advantages over Immanent in that it's a more concise and to the point as opposed to Immanent, and offers far less opportunity for the Powepoint pushers to wreak havoc, however, the latest twist on the situation is a system designed for Pompous Management Pests (in the interest of keeping this a family-oriented discussion I've edited the original definition) that we shall call  for purposes of this discussion "The Contrivance". Said Contrivance is one of those things that gives you excutive dashboards, issues tracking and all the other esoterica needed to run a large scale program, however it has a teeny problem. It stinks. There are some funny logic errors in there,  such as if a document that needs an approval has a minor edit, it resets the entire program to Red (the traffic light model works very well in program management) until the approver reapproves it. Needless to say, if a C-level type decides to check his executive dashboard online, and sees the entire program going Red, someone would best be advised to check out emigration after the chewing out that will result.
As I've previously mentioned, a couple of large clients had purchased Immanent, and I actually encountered one that rebranded it as their own proprietary methodology. Said client was a very large financial conglomerate, who was in the process of expanding away from financial services into some oddly diverse ventures, but the end result was of course the same old "let's create that ongoing revenue stream" thing. The client had some top-notch folks working for them, including probably the best CICS guru I've ever met. The only problem was that the program had a very wavering line of sponsorship in the higher levels of management, and that the system that they were trying to implement just didn't have the performance that the client was demanding, despite throwing a lot of mainframe MIPS at it. These guys were really tweaking this puppy and they still needed about a sixfold increase in performance to make their batch windows. I'm a great believer in divide and conquer, but this would've been a very interesting distributed database, in the Chinese sense of interesting. Not to mention there were some very critical windows at month, quarter and year-end closing that had no leeway. If something went bump in the night, oy vey.
We found ourselves ensconced at the client, who needed a realistic project plan for what it was going to take to implement this kaiju project. The client had already produced some plans, needless to say in Microsoft Project, which works very well until you try to level resources, and when I took a look at the existing plans, my reaction was basically, "Geez, Immanent Mark I.  Didn't think anyone was still using this!". The Boss (who as I noted is actually a very cool person) delegated the task of taking the existing plans and fully Immanentizing them to me, as I was the only person within a hundred mile radius who'd ever actually read the dreaded white binder. The big problem we had was that while the client had lots of smart people, not a one of them had ever been trained on this beast, and the rest of our team had never seen Immanent Mark I (some had seen Mark II, but had never actually figured out how to use the damn thing). The rest of the team was trained on antecedents of RELBUM, and the nominal project manager was completely mystified by Immanent. The deliverables they had spec'd out and planned didn't align at all with Immanent, and I was given the unenviable task of converting their milestones and terminologies (half of which were in a foreign language, fortunately somewhat comprehensible to me) into an Immanentized plan which would be presented to some senior duro come.
Needless to say my laptop's critical need detector went off and I had a hardware meltdown several hours before the plan was due. Not liking the idea of "my dog ate the homework", I attempted to recover as best I could, but the client's security policies, apparently adapted from something written by the Sicherheitspolizei, were somewhat restrictive, and I couldn't install my licensed copy of Microsoft Project onto one of their desktops. Their security policies were quite effective, except in the case of a very naive young foreign programmer, who clicked on a "Free Scratch and Win" popup and totally hosed their ultra-secure desktop build.  Unfortunately the rest of the team's laptops were otherwise engaged, and it took a quick and expensive trip to the local CompUSA to get a laptop that I could install the minimum tools needed to get the Immanentized plan, plus a really intense session trying to recreate two days work before the big meeting with the honcho. Thanks to some really great teamwork helping me level the resources before we announced that the project would end somewhere in the next epoch, we got the plan into Mr. Honcho's inbox before a major explosion. We only hoped we had guessed right on the number of resources....
The plan landed with a thud, as Mr. Honcho was not interested in a detailed line item plan. He wanted the 100K foot level of detail. The entire discussion of the detailed line item plan took about thirty seconds, and basically consisted of our senior guys doing the setup, him going "yup", and quickly moving to the tochis afn tisch topics of just how much this puppy was ultimately going to cost, and little things like progress payments and liquidated damages. Mr. Honcho then asked as an afterthought why we had bothered to do a detailed plan when his guys were perfectly capable of doing one. I figure the line item plan cost them somewhere in the neighborhood of about $25K. 


<< Home

This page is powered by Blogger. Isn't yours?

Technorati search