Archives for posts with tag: Project

I’ve written a few times before about tackling large projects and biting off small digestible or achievable chunks to eat away at the project and make it doable.

One thing I find useful when tackling a large project – though not too large or else the parameters may change and you have to start again – is to do the fiddly stuff first. If you’re writing a document, get the contents right before you move on to fill in the big gaps. If you’re working on a large deck, do the cover slide and the end slide first and get the title and content conventions down before you do your slides. If you’re working on a spreadsheet, to the tidying up and formatting of cells before you put the main body of numbers in.

You have to do the important parts, the major bits, so getting the fiddly stuff out of the way means they won’t get forgotten about or underserved at the end when you’re flagging. Yes, you run the risk of not getting the big, important part finished, but you have to get it done so you’ll get it done, and if there’s a time deadline, then your focus, your productivity and your output will increase accordingly.

If you do the fiddly stuff first, you know you’ll finish. If you leave the fiddly stuff til last, you run the risk of wanting a break after finishing the big stuff and not finishing the whole thing.

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.