[GeorgeCH]

Dear fellow INTJs,

Do you ever find yourself missing a small but crucial detail that, if not addressed, could unhinge an entire greater undertaking (otherwise meticulously planned?)

Here's a simple example: as part of the project I am coordinating at work, we had to collect something like 4,500 scanned documents from an international organization distributed worldwide. I happily planned everything, including deadlines, which offices to contact, exactly which documents we are going to need, how long this is going to take, how it fits into the greater project effort, etc.

See where the problem is yet?

That's right - somehow, no one (worst of all, not even myself - and I am above-average computer literate) had bothered to ask themselves the very simple question of how the hell can we reasonably ask someone to send 800 scanned documents to us by e-mail. Over a thirteen business day period, this would require sending 61 scanned documents each, or 61 x 4MB = 244MB / day.

And the worst thing is? The thought didn't hit me until 20 minutes before I was to present the project plan to the Senior Management.

Now, granted, screw ups happen. Sometimes, we all skip a detail here and there - that's unavoidable. But exactly what do you, my dear fellow INTJs, do to ensure that small details like this are thought about and planned for as part of your planning and process mapping effort? Is there a mental process you employ to validate small details in your planning?

Planning and process mapping is fun (and even sexy); but, more often than not, it's the details that kill execution.

[IreOfDesire]

The case that you described here doesn't look like a small detail whatsoever. I'm a project manager in IT so this might be the reason why I'd never overlook such a thing.

However on the original question - try to share your plan with the rest of the team and it is very likely someone who is usually annoyingly punctual (STJ) to be helpful raising questions about those minor details that can turn out to be crucial. INTJs do have the habit to be quite secretive of what their real plans are, so try to fight this trait by finding a nice critical sensor who can review your plans and find the things which you've might overlooked. 80% (or more) of the issues that guy would raise will actually be irrelevant but pay attention and try to find those 20% that could shake your boat.

[GeorgeCH]

IreOfDesire,

You're right in that it's not a small detail by any stretch of imagination (in fact, the project I am managing is a cross-functional HR / IT effort, and I am coming at it from the HR side). It's just that it is a lot easier for me to map a process out on an abstract in abstract terms (XYZ sends us 100 documents by July 18) than drill it down to the painful detail (XYZ uses the Organization's shared network drive to upload the documents; smaller offices use e-mail still). These sort of things I skip without even thinking about them - and, as demonstrated above, they can easily blow the whole thing up if not anticipated and addressed.

Regarding sharing - this is actually exactly what I do. All my process mapping (and subsequent project planning and effort estimating) are always collaborative exercises - while I might retain the final say, I also acknowledge that specialists always have a better idea of their specialist domain than I do (otherwise, they shouldn't be specialists in the first place). On a more general level, I acknowledge that there are details I can miss, which is why I always prefer to have a plan shared with the team and get their inputs - not because I want them to tell me what to do or to somehow dodge responsibility, but because I want to give others the chance to perfect the project plan and the project flowchart by telling me what, if anything, I missed.

Incidentally, we do have an annoying punctual person on our team (so punctual that she can drive even the director-level project sponsor crazy), and she didn't see it either (in fact, she was the one who had originally suggested that the whole thing can be done easily - just scan 'em and e-mail them).

I guess what I'm wondering is - if I know I can overlook such a thing (based on experience), and that the team can overlook such a thing, what can I do, internally and mentally, to minimize such risks?

[shivasprogeny]

I try to think through problems like this from different perspectives. So, for example, if I'm trying to revise a piece of the software our company uses, I'll have an idea of what the solution is. But then I also think "How will my average user feel about this? If I'm a supervisor, will this help me make the right decision?" etc.

In your situation, you might have put yourself in the place of one of these organizations. So you give them task of sending X number of documents, how will they complete that task?

It's not foolproof, but really no approach is--that's why it's call overlooking!