When do you punt?

On a project where you are dependent not only on your skills but those of a partner organization, when do you punt?

I have a dear friend that I play Madden with from time to time. One of the things that he found out in a game once was that you could, against all odds, run a pass play on 4th and 30+ yards and pick up a first down more often then not. A huge flaw in a game dependent on producing a consistent viewing/playing scenario. In the real world you pick up 4th and 30+ 1 time out of 50. In the game, he was picking this up 2 out of 3 times.

It’s an interesting problem with partners. You can’t throw out the baby with the bath water, but there are times when at 4th and 30 you want to punt – it’s the right thing to do. But, as it is a partner you are often forced to levearge a long risky pass rather than punt.

So, when do you punt your project?

Clarity of communication, does it mean brevity?

I have been thinking about this for a bit, the difference within the various types of communication we have.

I communicate differently depending on the audience and the intent of the communication. My kids are often 2, or even 1 instruction at a time. Co-workers may be 9, 10 or even more instructions at one time. Other adults in social situations you may drop that down to 3 or 4 instructions.

But it seems to me that communication should be more focused, perhaps as we communicate with children in the sense that I think we place too much emphasis on the ability of another person to remember a complex set of instructions.

So why is that we take critical communication (co-workers) and add such layers of complexity? Again it seems to me that effective communication would be more focused on driving to single requirement, a single task rather than adding complexity to the communication.

My children can focus on the one job I give them. My co-workers often have 10 or 12 other people requesting data from them.

Its a painful lesson to learn.

.Doc

Is your project on fire?

We’ve talked about projects that are on the rocks, or in trouble. what about the two sides of a project on fire?

Good:
Things are really moving fast – in fact the project is chewing up chunks of ground and appears to be on track to finish way early

B.

Bad
Everything is failing, the project is falling around your ears. The smoke alone from the burning embers will choke you.

What do you do when your project is on fire? The natural tendency on the good side is to informyour sponsors that you are in fact going to finish early. That is a bad idea, because you never know when the floor will move up or down on your project.

On the bad side the tendency as we’ve talked about before is to look for a way out (see lighthouse). That is also the wrong method.

The goal here is did a good job in the requirements phase. If you know you did. Then let the project ride, either way. If you didn’t gather the right requirements now is the time for a reset of the project.

Go back to the requirements phase and see what you missed. Often the missed item is relavent in the sense that it is what is causing the flames (good or bad).

best on your projects!

.Doc

Travel as a time to catch up

So how do you use your airport time?

I catch up on blogs read architecture documents and focus on the things I don’t have time to finish the rest of the time.

I also like to watch people as the walk by. The conversations you can image are incredible. Arguments, dicussions and simple conversations can allow you to learn the nuances of communication. You can, without participating in a coversation learn to catch the contextual clues of communication.

Plus you get some great stories:

.Doc

System failure and how do we recover?

Interesting problem – when a system fails how do you recover?
Automated?
Human intervention?
Most system failures if they are systemtic would require human intervention, but when do you do that?

Recently I have been interacting with a company that is famous for it’s automated system. Only to find out the automated system is only a tier 1 response. Tier 2 would in fact require a human to intervene. Now, because of customer service is that in fact the right thing to do? Listening to someone pound their keyboard into dust as they are trying to help me isn’t effective for me. It may be for other people but not for me.

So when should your system be automated in recovery and when should a human being intercede?

It’s an interesting developmeant and architectural question.

.Doc

Can the illuminated path lead you astray?

Many of the archtiects I know, shout patterns for all solutions. Patterns are great tools to be used for many of the solutions presented to us, as architects. But patterns ultimately are focused on mature solutions rather than emerging solutions.

So in the case of an emerging solution, the path illuminated by patterns may lead you astray.

An interesting metaphor a friend once shared with me was the concept of patterns as stepping stones in a garden. The metaphor fits very well with the concept of patterns working well for established solutions (following the path). But the metaphor also points out the gap between the flagstones and therefore the failure within patterns to cover the unexpected.

So how do you “ensure” you don’t trip over the flagstones when you go off the beaten path?

Communication and planning the two cornerstones of the unknown. If you don’t know what happens next having a solid plan and communications structure will help you move forward.

.Doc

Running so fast on a project you forget why you were running

So what do you do when you realize that you took the wrong fork on a project because you were running so fast to get things done that you missed the warning signs (to paraphrase “on the road ahead…”)

The alignment of strategy and tempo of project are critical. How we structure the project, how we build the plan and the tempo of that overall project is a critical.

It’s sort of like running. You have to set the right tempo when you go out for a run. If you run too fast in the beginning you will lag at the end. If you run too slow its really hard to pick up the base at the end. Tempo is a critical component of a project.

So, plan your tempo now!!!!!

.Doc