Your Day Job vs the Project
Most people working on projects have another job.
The project is something they are expected to deliver alongside it.
That is perfectly normal.
A business buying a new piece of equipment isn't going to create a project team for six months.
The Operations Manager will be involved.
Finance will have something to do.
IT might need to help.
Someone from the supplier will be involved.
And everybody will carry on doing their normal jobs at the same time.
There is nothing wrong with that.
The problem starts when we pretend the project doesn't take any time.
The day job normally wins
Think about what happens on a Monday morning.
A customer has a problem.
Someone is off sick.
A delivery hasn't arrived.
There is a production issue.
Your inbox has filled up.
Then there is that project action you agreed to do last Thursday.
What gets dealt with first?
Usually the day job.
And that is completely understandable.
The day job has immediacy.
The consequences of not doing something are obvious.
The project is different.
That action can probably wait until tomorrow.
The project meeting can move to next week.
The decision can wait until somebody has a bit more time.
Nothing particularly dramatic happens.
Until all those little delays start joining together.
Everyone can be busy and the project can still be going nowhere
This is worth remembering.
A project can be full of extremely busy people and still not be making much progress.
Because projects don't move forward simply because everybody is working hard.
Things are connected.
One person needs to finish something before somebody else can start.
A supplier is waiting for a decision.
Training can't start until the system is ready.
Installation depends on the equipment turning up.
And suddenly the two-day delay that didn't seem particularly important has affected another three activities.
This is why somebody needs to look across the project rather than everyone simply looking after their own bit.
A name in a project plan isn't a resource
This is one of my favourites.
We put somebody's name next to an activity in a plan.
Excellent.
Resource sorted.
Except it isn't.
They already have a job.
If they have 40 hours of normal work next week and the project plan expects another 10 hours from them, they haven't suddenly become a 50-hour resource.
We have just created a plan that doesn't reflect reality.
The important question isn't:
Who is doing it?
It is:
When are they actually going to do it?
That can be a much more uncomfortable question.
But it is also a much more useful one.
Plan around real availability, not hope
This is one of the basic principles I use when looking at projects.
If somebody can genuinely give the project half a day a week, plan on half a day a week.
Not two days because that is what the project needs.
If the project needs two days, something has to change.
Move some of their normal work.
Give the activity to somebody else.
Bring in additional support.
Move the project date.
Or accept that something else isn't going to happen.
Those are real management decisions.
Putting an impossible date in a plan isn't.
Ownership makes a big difference
The problem becomes worse when nobody really owns the overall project.
Everyone has their own actions.
Everyone is doing their bit.
But who is looking across the whole thing?
Who notices that three activities have slipped?
Who chases the decision that hasn't been made?
Who spots that the supplier now needs an answer by Friday?
Who says that the current plan no longer works?
Someone needs to be aware of these things.
That doesn't automatically mean employing a full-time project manager.
For a smaller project, it might only take a few hours a week.
But somebody needs to genuinely own delivery.
“Keeping an eye on it” isn't the same thing.
If the project matters, protect some time for it
This is probably the simplest answer.
If you have decided a project is important, give people some space to deliver it.
That might mean blocking out Friday morning.
It might mean temporarily taking another responsibility away.
It might mean agreeing that somebody won't attend a few routine meetings.
It might simply mean the boss saying:
This matters. Make time for it.
Because if the message is:
“Deliver this important project, but don't let it interfere with anything else”,
there is a fairly obvious problem.
This isn't an argument for a dedicated project team
Most smaller projects don't need one.
People can deliver projects alongside their normal roles.
Businesses do it every day.
But the project needs to be designed around that reality.
That means:
realistic timescales;
clear priorities;
genuine ownership;
protected time where it is needed;
and somebody keeping an eye on how all the pieces fit together.
None of that is complicated project management.
It is just being realistic about how the work is going to get done.
One question worth asking
Look at your current project plan.
Pick one of the important activities.
Then ask:
When is that person actually going to do it?
If the answer is:
“When they get a chance”,
you might have found your problem.
No Fluff takeaway
The project isn't being delivered by spare capacity that magically appears when you need it.
It is being delivered by people who already have jobs.
If the project matters, give them the time, priorities and ownership needed to deliver it.
Otherwise the day job will win.
That feels much closer. The lines “A name in a project plan isn't a resource” and “Plan around real availability, not hope” are particularly on-brand and connect directly to the presentation.
Not sure whether the project is realistic?
If you are not sure whether the project has the right ownership, enough resource or a realistic plan, the No Fluff Project Assessment gives you a structured way to take a closer look.
It helps identify where the project really stands, what is getting in the way and where attention is needed before small problems become bigger ones.
Comments