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.
Paul Dilger's blog 
For what feels like the first time, in your many many covered subjects, you have LITERALLY nailed exactly what I do on a daily basis: Setting ground rules amongst disparate groups and individuals; establishing frameworks for them to communicate and execute inside of; making sure all bases are covered for ‘my boss’ (the customer).
Music to my ears, as they say.
LikeLike
Glad to be of resonating service Andy, thanks for commenting :-).
LikeLike