By the end of your first week, you may have sat through a week of programme briefings and still not know what is actually worrying people.
The PMO walked you through the programme plan. The workstream leads took you through their most burning risks. The sponsor told you the outcome they expect from the programme. The systems integrator reminded you what the contract says. Finance showed you the business case, and how the investment decision was made.
Every one of them described the same programme.
And none of the descriptions quite agreed.
Resist the urge of solving this problem in your first week. It may be the most useful thing you have learned.
Everyone will tell you the first 30 days are about learning the programme. And they are.
But there is another job happening at the same time.
In your first 30 days, you are not the only one learning. The programme is learning you.
People are working out which decisions you will make yourself. Whether you want bad news early or only once there is an answer. Whether you will take a position when the room gets uncomfortable. Whether every problem now needs to come through you.
Nobody gives you a briefing on that.
If I were taking over a programme tomorrow, these are the seven things I would want to understand before changing too much.
1. Work out what you have actually inherited
The status pack tells you what you inherited on paper.
The briefings tell you what you inherited according to the person taking you through the briefing.
Your first job is to notice any gaps between those versions.
The plan might say the integration build finishes in March. The architect tells you some interfaces are still not fully designed. The sponsor cares about holding the go-live date. Finance cares about the year-two benefits that depend on it. The contract has a milestone payment attached to the build.
None of those statements is necessarily incorrect.
Put them next to one another, though, and you start seeing the assumptions the programme is running on.
The temptation is to reconcile everything immediately and create one clean version of the truth.
I would resist that.
Every briefing in week one describes the same programme differently. The disagreements between them are the assumptions the programme is actually running on.
For the first couple of weeks, write down the disagreements instead.
Where does the plan say one thing and the people doing the work say another?
Where does the contract assume something that the delivery team does not?
Which benefit depends on an operating change nobody owns?
Those disagreements are often more useful than the status itself.
They tell you where to look next.
2. Find out what the sponsor expects you to decide
This is one of the boundaries worth establishing early because discovering it by accident can be expensive.
Some sponsors want a programme director who brings recommendations, exercises judgement and makes the decisions that come with the role.
Others want to remain close to a much wider set of calls.
Either model can work. And you need to find out, which model your sponsor is applying.
What does not work particularly well is finding out which model you are in during your first steering committee.
So take the significant decisions you can foresee coming over the next quarter and put them into three groups:
→ decisions I own
→ decisions where I put forward a recommendation
→ decisions the sponsor owns
Then put the list in front of the sponsor.
I would much rather discover in week two that the sponsor expects to make a decision I thought was mine than discover it after I have already made it.
And the reverse is equally useful.
If you keep taking decisions upwards that the sponsor expected you to make, you may think you are keeping them close to the programme. On the contrary, they may be wondering why they appointed a programme director.
Every sponsor has a line between their decisions and yours. Find it on paper in week two, before a steering committee finds it for you.
This is less about creating another RACI and more about learning where your judgement is expected.
If your sponsor attends more than they decide, I have written before about why most programme sponsors never actually sponsor.
3. Find where the programme is running on heroes
Listen carefully when somebody says:
“We couldn’t do without her.”
It may simply be well-deserved praise.
But I would also treat it as a reason to look closer.
Maybe it is the architect who knows every integration. Or the project manager holding five workstreams together. Or the business lead who resolves problems through a few phone calls before they ever reach the formal governance.
Sometimes the person is exceptional.
Sometimes the programme has quietly built part of its operating model around that person being exceptional.
The integrations sit in one person’s head because the design was never properly documented.
Five workstreams stay aligned because one project manager spends their week absorbing the gaps between them.
Issues get resolved informally because the formal escalation route takes too long.
A programme that cannot do without one person has built part of its operating model around them. Find out what stops working if they are away for four weeks.
There is nothing wrong with having exceptional people.
The risk is not knowing what would stop working if one of them disappeared for four weeks.
Your first few weeks may be the easiest time to see these dependencies because you have not yet accepted them as simply “how this programme works”.
Once you have, they become much harder to notice.
4. Listen for what people are reluctant to tell you
The formal risk register rarely coverthe whole programme.
Some of the useful information arrives after the meeting. Or in the last two minutes of a call.
It often starts with something like:
“Between us...”
“This isn’t in the pack yet...”
“I probably shouldn’t say this, but...”
That moment matters.
The person speaking is not only giving you information. They are learning something about you.
Can I bring this person a problem before I have solved it?
Will they listen?
Will they immediately escalate it?
Will they make me regret having said it?
Your reaction to the first piece of bad news teaches the programme how to bring you the second one.
Before reacting, I would do three things: thank them for raising it, ask what they have actually seen, and go and look.
The important thing is what happens next.
If your first response to uncomfortable information is to solve it for them, forward it to somebody else or visibly react before you understand it, people notice.
And the next concern may arrive later.
The person telling you the problem will remember that conversation far longer than you probably will. On a programme, that matters.
Your reaction to the first piece of bad news teaches the programme how to bring you the second one.
The next warning about the supplier, the data or the business readiness reaches you early only if the person carrying it expects something useful to happen when they speak.
5. Do not confuse being useful with solving everything yourself
You probably got this job partly because you are good at fixing things.
Your first month will present you with plenty of opportunities to prove it.
A cutover plan that does not add up. A contract clause interpreted differently by the client and supplier. A migration approach nobody can explain clearly. A decision that has been circling the programme for three weeks.
Of course, a programme director sometimes has to go into the detail.
The question I would ask is different:
Am I getting involved because this needs my judgement, or because solving it myself feels easier than getting somebody else to own it?
I have done this myself.
In 2017 I was programme director on a large ERP-enabled transformation for a global bank. I kept turning up to the design authority meetings where the detailed solution decisions were being made.
A solution architect should have owned that place.
I should have been hearing about the design decisions that materially changed the programme’s cost, date, risk or outcome.
But I stayed. The design was where I felt useful. It was also where I was least needed.
It does not mean programme directors should stay away from detail. Sometimes the detail is exactly where you need to be.
The problem starts when detail becomes the place you automatically go to whenever something is difficult.
Do it often enough and the programme learns very quickly that difficult problems belong to you.
Workstream leads bring them upwards instead of resolving them.
Meetings wait for you.
Decisions queue behind your diary.
And eventually the programme director becomes one of the programme’s dependencies.
6. Work out which meetings actually run the programme
The governance tells you where the programme is supposed to be run.
It does not necessarily tell you where it is actually run.
The real decisions may happen in the sponsor’s Tuesday call, the Thursday finance review and coffee conversations before the steering committee.
Your job initially is not to tidy that up. It is to understand it.
After an important decision, ask yourself where it was really made.
Who was in the room when the position formed?
Who influenced it?
Who only heard about it after the meeting?
Where are decisions actually debated and where are they merely ratified?
This matters because a meeting can look redundant on a governance and still be the one place where the sponsor thinks out loud.
If you remove it just because the governance looks untidy and you may accidentally remove one of the programme’s most useful conversations.
Do not redesign the governance you were given until you have found the governance that actually runs the programme.
So I would be cautious about redesigning governance in the first month.
First understand the formal governance. Then understand the informal governance underneath it. Only then decide what is duplication and what is doing work the organisation has never written down.
I have written before about the meeting before the meeting.
As the new programme director, one of your first jobs is finding out which meeting that is.
7. By day 30, have a point of view
I would not expect a programme director to have fixed a complex programme in 30 days.
I would expect them to know what they think.
After a month, you should be able to explain the programme in plain language and in under five minutes:
→ This is what I believe the programme is really trying to achieve.
→ These are the two or three things will most likely stop us.
→ This is what I think we should change.
→ This is what I would deliberately leave alone.
That is not the same as completing a diagnostic.
A forty-page diagnostic can describe the programme back to people who have lived in it for two years. A point of view tells them what you have concluded. It also gives the sponsor something to challenge.
That matters.
By day 30 your sponsor needs your conclusion, stated plainly enough to challenge. The forty-page diagnostic can wait.
You do not need a sponsor who agrees with everything you think. You need to discover where your judgement and theirs differ while there is still time to do something useful with the disagreement.
What I would not do in the first 30 days
I would not rush to reorganise the team.
I would not redesign every governance forum.
I would not promise a new date until I understood how the existing one was built.
I would not assume the people described to me as “difficult” are actually the problem.
And I would be very careful about announcing that the programme needs “more discipline” before understanding what the people on it have already been through.
There is a familiar piece of advice when starting a new leadership role: secure an early win. On a live programme, one of the most tempting early wins can be a new date.
The programme has been struggling. Confidence is low. You arrive, challenge the plan and announce something more credible.
It feels decisive.
But a date is only as reliable as the assumptions that sit underneath it.
Until you understand what the old date was built upon, there is a real danger that the new one rests on exactly the same foundations, except now it has your name attached to it.
There is, of course, an important exception to most of the above.
If you inherit a programme six weeks from go-live, a supplier is walking away or the sponsor has already lost the board, you may not get a comfortable 30-day learning period.
You may get a week at the most. You decide with what you have.
But I would still ask many of the same questions.
I would just ask them faster and accept incomplete answers.
How to tell whether the month worked
At the end of 30 days, there is an obvious way to measure progress.
You know more about the programme.
But I think there is another measure that matters just as much.
What can the people around you now say about you that they could not say on day one?
Not:
Roman knows the plan.
That would be a fairly poor return on a month.
Something closer to:
I know what I can decide without asking him.
I know when to bring him bad news.
I know what he thinks matters most.
I know which problems he expects me to own.
I know he will take a position when the programme needs one.
That is the other half of your first 30 days.
You were learning the programme.
The programme was learning how to work with you.
If, after a month, people still do not know what they can decide, what you expect them to own, whether they can bring you an unresolved problem or where you will take a position, then you may have learned a great deal about the programme.
The programme may still be waiting to learn about its director.
If you are inside your first 30 days now, I would start with two pieces of paper.
On the first, write down where the different versions of the programme do not agree.
On the second, write down which decisions you believe are yours, which ones need your recommendation, and which belong to the sponsor.
Take the second page to the sponsor before the end of the week.
And if your first 30 days are long behind you, those two pages are still worth writing.
They may tell you something about the programme you are running today.
— Roman