It never ceases to amaze me how much confusion there is, and much talking across purposes, when we haven’t agreed the basics in a project.

Especially an internal project. When it’s an internal project, we’re all taking with people inside the business so a level of understanding is assumed. All the more reason to make sure we define what we’re doing and the parts of what we’re doing, to avoid confusion, miscommunication, missed deadlines and frustration.

It’s the best way to avoid this kind of conversation:

“Where’s the rest of it?”

“What do you mean, the rest of it?”

“Well, I kinda assumed you were going to do this, this and this…”

“No, I think this and this was supposed to be all we were doing for today.”

“OK, I need to do a reset with the Chieftain, then. I don’t think we have everything s/he’s looking for.”

Sometimes it’s only when you get into the detail of a project that you uncover the misunderstanding. All the more reason to get your internal naming of parts of a project right, and define what’s involved. Otherwise you end up over-promising and under-delivering. Not good, especially when it’s an internal project.