What

A set of rules for having efficient status meetings.

Why

Reading is faster than listening.

Status meetings should provide communication, not problem-solving or decision-making.

People don't usually need to be in all of each meeting

Who

Up to seven people or groups. If more than seven people, report by group. Five is better.

When

Every reporting period. Could be daily, every other day, weekly, monthly. First thing in the morning is a good time.

How

Everybody types out a PPPD the night before the meeting. A PPPD is four lists:

• Progress since the last meeting. Progress can usually adapted from previous Plans, from timecards, from personal To-Do Lists, from calendars, whatever your personal system is
• Plans until next meeting. Anything that stays on Plans for a second PPPD in a row should be marked (second time, third time). By the fourth time, you should move it to some wish list, because it’s clearly not a realistic, short-term Plan.
• Problems which are interfering with progress.
• Discussion points. This is anything you specifically want the group to talk about; it doesn't have to be an item from your P lists.

All PPPDs are distributed to all participants by end of business the night before the meeting. The Secretary reminds anybody who is late. Participants should read all of the PPPDs before the meeting.

The status meeting has three parts. The secretary manages the meeting.

• Review
  • Review goes one PPPD at a time, in the order they were sent.
  • Review consists of author saying good morning, asking if anybody has questions or responses to any of their PPP items, and then Q & A as needed.
  • Talking during Review is limited to brief question and answer, clarification, etc. Anything more than 30 seconds should be interrupted and added to the end of the Discussion list for that PPPD.
  • Continue until all people have Reviewed.
• Big Discussion
  • Go around all of the PPPDs again, in the same order
  • For each PPPD, raise each of the Discussion items in the order written.
  • If it only concerns a few people, bump it to Small Discussion.
  • If discussion goes more than a few minutes, bump it to the end of the meeting, or later.
  • Continue until all PPPDs with Discussion points have been covered.
  • Anybody not needed for Small Discussion leaves the meeting.
• Little Discussion
  • Discuss remaining discussion items, if any, in the appropriate smaller group
  • The secretary takes notes on any decisions made, and sends the notes around, and reminds people when the next PPPD is due.

Failure modes

Nobody reads the PPPDs. If this happens, go ahead and spend the first ten minutes of the meeting letting everybody read quietly while music plays.

People are late or miss meetings. You can punish the latecomers by making the last PPPD author be the secretary for the next round, but they will probably be a lousy secretary and you will have to nag them to nag other people. Unless your entire team is well-motivated (or anal-retentive), the natural nagger should remain the Secretary.

Acknowledgements

The PPP meeting process was passed tome from one of my mentors, Grant Tegtmeier, who also helped refine it into PPPD. The Progress/Plans/Problems template, of course, predates us all and presumably can be found in Sumerian tablets explaining why the new ziggaurat is running behind schedule.

Moving. My new theory is that it's a bit like pregnancy. It's all-consuming while it's happening, and afterwards your life is not the same, but you forget all of the pain or else you would never ever do it again. For the record, I only needed one of those storage pods, and I didn't come close to filling it.

While a dog is much less likely to support you in your dotage, they still require a bunch of maintenance. I wrote up a checklist of things that I was afraid I would forget. Of 13 items, fully five were about Kona.

The airline had their own list.

So. Washington, District of Columbia. By population, it would be one of the smallest, but not the smallest, state. They didn't get the right to vote for the president until the 1964 election, they don't have a senator, and their representative in Congress can't vote. A recent deal to finally give DC a vote in Congress was sabotaged by the NRA. The whole issue seems to be a sore spot in the District.

We landed on a Wednesday, took refuge with a college friend and her family in Northern Virginia, and set out Thursday in a rental car to find an apartment. We checked out about eight apartments in three days, in most corners of the city.

The District is majority black and has a poverty rate higher than any state but Mississippi but is embedded in a fairly wealthy and majority white metropolitan area. In America, race and class are as closely related as electricity and magnetism, so figuring out where you can afford to live is a fairly charged process. My office is in the northwest quarter, and NW also has the nicest houses and neighborhoods and all of the embassies and I looked hardest in NW, but I also looked at a place in Northern Virginia and a place in Northeast and a place by Howard University, among others. Some places were nice but in fairly desolate neighborhoods. Other places were not as nice. This carpet was even worse in person than in the picture.

There are bunch of nice stone townhouses, but mostly they are divided into a house, which is too big and expensive, and an "English" basement, which is too dark. But I would have liked to have lived in a little garret like this one.

Consistent with that theme is this building, in which the top floor of office space is for rent. If I'm ever in charge of any sort of evil organization bent on world domination, I think I would try to get this space for my headquarters:

One apartment I looked at was quite close to this lovely monument to ignorance:

But the apartment I ended up in is only two blocks from this awesomely malicious foolishness:

My new apartment is also close to this exciting museum. I'm assuming they're sharing space with the National Museum of American Jewish Sports History to save money, but that's just a guess.

So. I ended up here:

It's not quite fully equipped, compared to some others I saw; no garbage disposal, no dishwasher, no washer/drier, no microwave. And it faces a street that is completely gridlocked through rush hour and most evenings, in both directions. The fire department is two blocks away and treats the street like their favorite shortcut. But it's not small, and it's incredibly walkable; the office is 1.5 miles away, the Metro is five blocks. I can walk to groceries, walk to coffee shops (not counting Them, of which there are probably fifteen or twenty within a mile), walk to hardware stores and hundreds of restaurants and many shopping streets, walk to the brand new dog park:

The apartment was a little bare at first. It's an old building, with plaster walls covered with lead-based paint, and lots of patches and accumulated cruft. The wooden floor is probably original, and looks okay at a glance, but when you try to clean it you realize that those hairs and bits of dirt and gunk are all under the sealant.

After a few trips to IKEA, we are much more comfortable.

So here we are. Busy making tracks.

Here are my notes on the business process modeling training I attended the other week, which may be of interest to people who ... model business processes?

Instructor

40+ years of experience, continues to work as a consultant as well as training. Impressed me with his practical, thorough knowledge of the subject matter.

Summary:

Business analysis is a way to understand the as-is, discover or create improvements, and describe the to-be. A key tool is business analysis is modeling, and a very common way to model is by drawing pictures. Another way to analyze a business process is with a use case.

We did two days of modeling, and one day of use cases.

Types of business analysis

• functional
• problem
• exception
• timing
• information
• detailed process

We covered a few standardized types of diagrams. They are primarily useful to help people communicate within a single project; maintaining a library of detailed process documents and keeping them current with any changes is very expensive and probably not woth the trouble. Instead, create documents to help specific groups of people work through specific problems, and set them aside once those problems are solved.

"Context-level diagrams." High-level diagrams that show a business process. I think this is what Yourdon calls a Data Flow Diagram. It has four ingredients:

• information flow: arrow with noun as label
• process: rounded rectangle with "transitive verb-object" label
• data store: short, wide rectange with right side open, noun as label
• external entity: rectangle, noun as label

You can then apply some rules, such as, no arrows between squares, which means, no data flows between two different external entities. By putting everything into a model and then applying mechanical rules, you can uncover both the incomplete parts of the model and, more helpfully, places where the model accurately represents a broken process.

"Question File." A list of questions that you accumulate as you analyze a process. You then keep working through the list until all questions are answered (or dropped). I did this on my last project without realizing that it was a thing, with a name. The main value of much of the modeling is to generate questions, which in turn will expose parts of the process that weren't fully thought through or which don't or won't work as designed.

"Hierachical Model". When the process model gets really complicated, i.e., bigger than one page, you can make a one-page high-level model and then decompose processes on that page into more detailed models on their own pages.

"Wall Chart". For people who don't like hierchical models. Everything is modeled at the lowest level, all on one big page.

"Main Line". The normal path through the process should start on the left side, halfway up, and proceed across the page horizontally to end on the right side, halfway up. Then exceptions and alternatives go above and below, and it's easy to distinguish the most common path from the wierder paths.

"Swimlane". Parallel lines added to activity diagram or process model to show segmentation along a dimension, e.g, a department

"Business Rules." I've been using this term for a long time, without a concrete definition. The way I've heard it used implies a definition like "the subset of product requirements that are specific to a customer's business, as opposed to technical requirements, or requirements that are about some functionality that isn't directly related to the customer's needs. By this definition, for example, the list of users who have access to post things is part of business rules, but the details of how password recovery should work are not.

"Business Rules" is a term invented by Barbara Van Halle in the 1980s and 1990s. As I interpret the instructor's telling of Van Halle's intent, a business rule is a functional requirement for a system which could change, at least within known boundaries, and therefore should usually be implemented as a user-configurable feature within a program. For my previous example, the list of users who can post things will clearly change as users come and go, and so some user needs the ability to administer that list without changing the program. Password recovery might have some business rules too, such as how many times you can ask for your password. But the fact that the system emails your password, rather than faxing it or calling you with it, is probably not a business rule, and can be hard-coded into the system.

Five types of business rules:

• facts
• action triggers
• action-restricting rules
• algorithms
• inferences

"Near learning" vs "Far learning". These were new terms for me. After googling, it appears that they are from the "Transfer of Learning" theory, dating back to 1901 and intending to explain how (or if) people take something they learned in one context and apply it in another context. To take a silly example, If you learned how to tie your shoelaces, then tying boot laces would require near learning, but tying the knots on a sailboat would be far learning. Where I think this applies to what we are doing is in customizing training for users. One thing that often confounds users in training is that the examples may not be relevant to their normal work. We saw this in training in Macon: the sample business process that we practiced modeling had to do with orders and inventory and shipping, not with HR applications and vacancies. Learning the modeling requires one level of mental effort, and understanding the specific process to be modeled requires a different mental effort. Since we didn't already understand the process we were modeling, we had to do woth levels of effort, and they can conflict with each other. We were doing two kinds of far learning at once. We managed to work through it, but it slowed us down a bit.

The fact that users get confounded by examples can in turn confound us as trainers: "I'm trying to show you how to post a vacancy but you seem to be stuck on the fact that it's a Coast Guard vacancy, and you're in the Army. I know you don't post Coast Guard vacancies in the Army. Why can't you just pretend it's an Army vacancy?" But what's happening is that the user is being asked to do too much learning, and too much "far" learning, at once. Dennis and I were talking about customizing training materials. It's a big expense and something we may not have the capacity to do, but if there's any way to make it happen, I think it can really pay off by reducing the effort required by the trainees.

"Use Cases" (This is not a full summary, just my notes on the ideas that jumped out at me as new or better compared to what I knew before)

Use cases are helpful for describing interactions between the user and the system. They are not helpful for describing automated functions, batch jobs, etc.

Use the "T-shape" to show a dialog between the user (left column) and the system (right column)

A "scenario" is a blow-by-blow account of one actor doing all of the steps to complete a task, including the specific data input and output. It can be a stepping stone to a use case.

There used to be a distinction between "business use cases" and "system use cases"; this is being replaced by the concept of use cases on a spectrum of detail rather than two distinct types.

Andre Ethier booted pinch-hitter Pete Orr’s fly to right field in the ninth inning, allowing Justin Maxwell to easily score, and the Nationals averted their 100th loss of the season with a 5-4 victory over the Dodgers on Wednesday night. —AP

"Booted." Well. That's not how I remember it.

You can file this blog post under your choice of my pet themes, either the oxymoronism of sports journalism or the magic of baseball to illustrate concepts of statistics and truth. An "error" in baseball is an official thing, designated by a paid scorekeeper and affecting standard statistics. The Dodgers were charged with one error in last night's game. But in fact they committed two errors in the previous inning, and the error they were charged with was a good play, in my opinion.

In the bottom of the eighth, with the score tied, nobody out, and a runner on first, this happened. That's obviously a fly ball that should be caught, and either Kemp or Manny could have caught it with ordinary effort. But Matt Kemp apparently lost it in the lights, and Manny properly did not go running under the ball since Kemp, the center fielder, is the captain of the outfield and is responsible for directing the other players. Unless he screams "you get it, I lost it", Manny shouldn't be running to catch it, eyes up. So that's Kemp's error, but officially, losing a ball in the lights isn't generally an error. Sherrill then induced a foul out, which should have been the second out, and then got Dukes to ground into a double play (which should have been a single-play inning-ending third out). But. Hudson (I think; it might have been Furcal) throws wide of first, and the Nationals score a go-ahead run. The norm for scoring broken double-plays is that there's no "should have" for double-plays; if at least one out is made, there's no error on the play. But the same throw would have been an error if it hadn't come as the pivot of a double-play. The Dodgers give away a run with two errors, but neither is officially scored "E". Here's how the bottom of the eighth looks on my scorecard:

The Dodgers tie it in the top of the ninth. The Nationals load the bases with one out in the bottom of the ninth. With even a minimally ambulatory player on third and less than two out, any moderately deep fly ball wins the game. The Dodgers position their outfield commensurately with their option matrix: in, way way in.

The outfield is in this close because any ball hit over their heads is going to win the game whether they catch it or not. With less than two out, the runner on third can simply return to the base on any fly ball, wait until the ball lands either in a glove or the ground, and still be able to run home. So any defensive coverage more than three hundred feet from home plate is wasted, and playing this close in they can, for example, turn any bloop singles into outs. Orr hits a fly ball to medium-deep right, an obvious game winner right off the bat. Ethier's defensive prowess is intermittent (see FRAR and FRAA), but his arm is fine (and in fact, literally as I am typing this sentence, the night after the game and watching tonight's game live, Ethier just threw out a National at the plate running from second on a single to right). Still, to run backwards and catch a ball and then quickly throw it hard to home plate behind you is going to be a hell of a trick. Simply catching the ball has no value; he has to throw out the runner or the game is over. What actually happens is that Ethier runs crazily backwards, glove over his head, and gets to the ball, only to have it bounce off his glove. When the ball touches glove leather but isn't caught, it's almost always scored an error. But given his initial position, Ethier did well simply to get his glove to the ball, and it's entirely possible that he missed the catch because he was trying to catch it while positioning for a throw to the plate. Remember, just catching it is worthless, because the runner comes home and the game is over. So, the Dodgers lose the game on two bad plays in the eighth that aren't scored as errors, and took appropriate risks in the ninth, only to be charged with a pointless error. Insult to injury, the reporter then describes the fly ball, which bounced off Ethier's glove, as "booted".

That silliness aside, it was a lovely game. The ballpark is reasonably intimate, and non-corporately named. It manages to have no particular personality but also to not be bland; it's just nice, in a non-pejorative sense. There were enough of us Dodger fans in our area behind third base that our "Let's Go, Dodgers" chanting drowned out the booing from, basically, the rest of the field level on the third base side, and there were maybe twenty of us, so you can do the math on the attendance and allegiances. There's a Metro stop a block from the park, but Metro made my friends twenty minutes late, and then trapped us for over half an hour going home before making me change trains, so that a 15-minute incoming ride took almost an hour going home. And to make that even worse, they let us fill up a full train, maybe a thousand people, and then just wait there, with only one or two announcements and nothing like "it will be 30 minutes until this train even moves". If they'd said that, we could have just walked to a nearby station on a different line that wasn't undergoing track maintenance. It's the sheer indifference of the Metro employees to the passengers' well-being that makes it so frustrating. Let me be the next to say, Metro sucks. They put a nasty end to a pleasant night at the ballgame.

Although Kona has begun to mingle with the other dogs again (to the extent that she ever mingles with dogs: grudgingly and suspiciously), she returns from time to time to the north corner of the park to wait for the Hotel Lady to return.

Kona hit a trifecta on our walk this morning. I've included a map to help you.

Here's the flag of the first country she went on.

The second:

And the third.

Kona resumed her vigil for the hotel lady, although she did take some time out to chase other dogs, so perhaps the spell is starting to wear off.

We went for our night walk.

There were too many embassies to visit them all; maybe fifteen or more in a mile plus. At one point we passed Myanmar, Lao, and Ireland in 4 buildings. We conducted some business at this one. Which country is it?

The answer is here.

Our neighbor in Half Moon Bay tended to put up a different flag every few days, anything from India to Arizona to the Subcarpathian Voivodship.

Here in the heart of DC, there are so many embassies that I can't take a picture of every flag I pass. Instead, I'll be photographing only the flags of countries that Kona has been on, if you catch my meaning. For our purposes of pooch piddling, the front lawn of each embassy will be treated as national territory. So far in her life, Kona has been on the US, Singapore, and possibly Japan—we don't know if they walked her during her two stops as luggage. Today, she was on the country with this flag:

Can you guess the country? It's not so easy as Half Moon Bay; the embassy flagpoles don't face the Pacific Ocean and its gentle breezes. The answer is here.

My second week at my new job, they sent me to Georgia for training and to meet our technical team. Gus' friend Jill, who was in town for a convention, was kind enough to take Kona to her convention hotel and dogsit all week. I handed apartment keys to a friend of a friend of a friend last weekend, and left Kona alone in the apartment when I left Monday, and she was there when I got home Thursday night. If not for the facebook postings of Kona lounging around in a hotel room, it would have been like she was there the whole time

Friday night we met at the local dog park, which coincidentally just opened a few days after I signed my lease, and is two blocks from the apartment, and is extremely nice. I mapped our journey with the GPS in my google phone:

Kona instantly recognized her hotel lady, who now had her own dog with her. Jukebox is 11 years old, and ignored all of Kona's provocations, from playful nips and jumps to outright why-won't-you-play-with-me barking in the face.

Eventually another corgi showed up, Clyde, and I was talking to her owner as Jill and her friend Allison left. Clyde is a bit portly, but despite my experience keeping a corgi trim, backed up by showers of compliments from the vet, I didn't think it was my place to lecture his owner. Yet. While we were talking, I realized Kona had disappeared, and eventually I went and found her at the other end of the dog park, by the water fountain, waiting for Jill to return. A guy named Reyno, with two pugs, asked if I was her owner and said that he thought she'd been abandoned, because she was staring out of the fence so intently and desperately.

So, when Kona and I went back to the dog park this morning, guess where she set up shop, waiting for her hotel lady to come back.

In the last week and a half, I started a new job; took the civil servant oath [affirmation]; filled out the Declaration for Federal Employment (Optional Form 306), Employment Eligibility Verification (I-9), Statement of Prior Federal Service (Standard Form 144), Designation of Beneficiary (SF 1152), Education Data Update Form (Attachment 6 to FPM Ltr 298-42), Voluntary Separation Incentive Payment (Buyout) Certification Form, Self-Identification of Handicap (SF 256), Ethnicity and Race Identification (SF 181), Person to Contact in Case of Emergency (OPM Form 2927) and many others; went to a lot of meetings and met many people whose names I probably won't remember for another month; looked at eight apartments; signed a one-year lease, moved in, unloaded a storage unit, made extra copies of the keys, waited hours for the cable guy; mostly reassembled my bicycle; looked for and failed to find four critical retaining pins; sent in for Kona's new dog license; three times went looking for the new dog park in the wrong direction; twice went by the brand-new dog park when it was closed; given keys to a friend of a friend of a friend as part of the backup to the backup to get Kona taken care of during my first federal employee travel next week (Georgia, 3 days, business modeling training and meeting the technical counterparts to my Group); walked by the White House five or six times but only been able to see it through the trees once; and accidentally stumbled upon the Treasury. Details to follow. Today, a pilgrimage to IKEA.

Look closely at the middle of this picture. What's that by the streetlight?