Home | Login | Recent Changes | Search | All Pages | Help

MethodMadness

In my current gig, I am facilitating "business requirements" gathering sessions. These are good sessions in that we have the owners, users and builders involved in them. I leap then to working with these groups to build a shared documented understanding of what the application must do. To oversimplify, I work with them to document the functional specs in use cases (plus a few other appropriate models) and to document other non-functional requirements as they pop up.

The client uses Method/1 - so I have come to realize that the real purpose of our sessions is to create a PRD document of sufficient girth to snow management into thinking that substantial is happening so that they will fund this effort.

We had started down my usual path when I realized that one of the technical people was furiously figuring out how to reverse engineer bullet point requirement statements from our functional spec because that is what is required in the PRD.

Oh well. Is this productive? Is this why we have prescribed methods? BobKing 03/12/02

Or maybe not.

I have a speculation about your client story: I suspect that the PRD (is that a Product Definition Report? or something else?) is intended to get agreement on scope and benefits *before* the the project goes into detailed requirements gathering. I'm guessing the intention of the doc is probably to give requirements in a very coarse grained sift -- like classes of users, key events and major data entities. And since that wasn't done before hand, the team is creating it after the fact to satisfy some compliance checkoff.

Companies in your client's industry are often required to show some adherance to a defined development process in order to enter into (or stay in) certain lines of business (banking for example). So people are trying to adhere to some set of mandated activities/documents that was established by people who don't know much about building software.

(Last time I did work for your client, the were busy making two-sided, laminated cheat-sheets for their development managers so they'd know what sort of activities people building software should be doing.)

And powerpoint would not be my tool of choice for documenting requirements.

EstherDerby 03/13/02

Anyway, in recent (c. 2001) talks with some architect folks I discovered that Powerpoint is apparently a "tool of choice". I wondered if I took a wrong turn in the Universe somewhere. Have we gone from English to graphics, prototypes, pictures, lists, models and back to...bulleted lists?

Esther, the laminated cheat-sheet checklist is great.Very retro and post-industrial mentality.

New Math: If you take 5 laminated sheets and add them to 5 people today, do you get 5 project managers tomorrow?

So, Bob, what is the story behind the use of Method/1 and the evolution of any mandates around it's use?

- BeckyWinant 3/21/02

Method/1 was chosen as "the" methodology by two separate groups.

One group was within the technology department at a subsidiary. The sub had been pretty stable for a long time, there were a few massive development projects, but most of the work was keeping existing systems running or implementing new releases to enhance functionality.

It was a small group, and had a high proportion of managers who had never written code, and had little exposure to managing development projects. They were part of a flurry of process improment initiatives that started from the bottom up, but had become top down. I think though, that they bought into a goal of improving predictable project delivery and bringing more uniform quality to the results. (I believe the intention was to *improve* quality; though I'm not sure their strategy -- imposing one methodology -- was likely to have that result.)

The second group was on the "enterprise" level. They chose Method/1 in response to a bank audit that required evidence of defined and followed development practices. (As I recall the audit had been failed, and probably more than once.)

So there were two different (and possibly conflicting) goals in implementing the methodology. The bank audit goal won out in the implementation, or it seems so from what I observed.

All the developers in the department were sent to Method/1 training, which was a two/three day skim across the top level process boxes.

And then the VP of the development area declared that Method/1 implementation was complete, and it was now business-as-usual, and the responsibility of a different VP. This also meant that the afore-mentioned VP closed out the implementation project. This move probably saved him big $$ on his budget.

And it left the second VP holding the bag. The second VP chose a compliance check stance, which was consistent with the enterprise goal of producing evidence of following a defined development process.

One woman's story.

EstherDerby 032402

You've brought light to the scene: people assumed that a failed audit was the same as a need to improve quality. They slide into a methodology which promotes process improvement and maybe other benefits. Why not? It may be and it may not be. Digging too deep may have been more problematic.

It sounds like in the end the hierachy determines who got the real benefit. I wonder if any discipline from Method 1 survived (given that there were in fact good things buried it).

BeckyWinant 4-08-02