Perhaps this doesn't happen to most of you, but I think of songs at all sorts of times. While listening to Donald McNaughton's webinar, I thought of a lyric from the Talking Heads song "Houses in Motion" (here's a non-embeddable video if you're not familiar with the song):
Tell us a little bit, but not too much
I thought about this in the context of the seventh of James R. Chapman's project management principles:
Rule #7 - Write Important Stuff Down, Share it, and Save it.
The big question - what is important?
Part of what motivated the Agile movement was the feeling that more structured organizations were compiling information that was unimportant. Now perhaps there's a good reason to compile a certain level of detail, and it's something that you SHOULD be doing, but if the information isn't being used, why bother?
On the other hand, you do have to capture an adequate level of information so that you know what in the heck you're doing. Here's a start, even for those who think that all information gathering is worthless - capture the date that the project starts, and the date that the project ends. Note that you need to capture the REAL start date and the REAL end date. Even if you only capture those two data points, you'll be ahead of the game.
KATHY: How long will it take us to make a cool green widget? Two months?
JILL: I dunno. Remember how we originally thought the hot blue widget would take two months?
KATHY: Yeah.
JILL: Well, it actually took us 18 months to finish that project up.
KATHY: Oh.
Now of course you'll want to capture additional levels of granularity - I'm sure Kathy would want to know WHY the hot blue widget had a major schedule overrun. However, you have to guard against capture-creep.
AMY: Wow, I just had the most outstanding lunch with a woman from SuperCorp!
JILL: The company that makes the Transcendent SuperWidget?
AMY: Yeah. I spoke with one of their process monitoring specialists.
JILL: Wow! What does she do?
AMY: Well, have you heard about how all SuperWidget employees are required to submit hourly reports on their progress on every project?
JILL: Yeah, I heard about that.
AMY: Well, this woman checks the staples on each of the hourly reports to make sure they're straight.
JILL: Does she like her job?
AMY: She loves it. And you know what? We need to have someone here to do that job!
JILL: But we don't have hourly reports or staples. I email my status weekly to Mary.
AMY: Yeah, and you don't produce cool stuff, either! If we had staple angle inspectors, maybe we'd have cool products and alcohol-fueled golf tournaments like SuperCorp does!
Uh, right.
I've known organizations that didn't have any process and just went out and borrowed a process from someone else. The only problem is that they didn't understand the process that they borrowed.
The best first step is to document what you actually do, even if it's hallway conversations.
REQUIREMENTS GATHERING PROCESS FOR SHINYFACEBOOKAPP
Version 1.3
August 1, 2009
1. Requirements for the next iteration of Shinyfacebookapp are gathered via the process below.
2. The manager shall contact the department secretary and secure sufficient funds for the RGP meeting. The amount of funds to be appropriated shall be agreed upon at least one hour in advance between the manager and the director.
3. The manager shall contact the team and announce the time for the RGP meeting. This announcement shall be made at least one minute before the meeting commences.
4. The RGP team shall consist of the manager, all developers who have not engaged in a shouting match with the manager within the last four hours, and anyone else who is tapped on the shoulder by the manager and asked, "Thirsty?"
5. At the designated time, the RGP manager and team shall walk across the street to Floozy's Sports Bar (or another location as designated by the manager).
6. After the manager has consumed at least two beers, the manager will shout, "So what are we gonna code next?"
7. The RGP team, the manager, the bartender, and assorted passers-by shall submit ideas for a period not to exceed three hours.
8. At the conclusion of the RGP team meeting, the manager shall go home, sleep off the hangover, try to remember what was said, and come up with his/her own set of development tasks for the next iteration.
Hey, it's a valid process!
And if you've read through the entire Prodject series, thank you. (If you missed the earlier installments, start here.) This concludes the series...unless I think of something else.
