Starting Up a Program

Ok, your organization decided to launch a large program, could it be the transformation or completely new R&D or any other non-standard project monster.

Firing it to full-blown sailing engagement is a massive job.

Assuming all initiations steps are done like setting goals, initial budget, business case, getting approval from all stakeholders, start building organization, resources, …

From my perspective a very next and one of the most challenging steps in getting the schedule right.

It seems the standard step and relatively less complex than anything before.

Then why so many programs do struggle to get schedule stabilized, for the very long time from program launch?

Let me share my experience on this.


Scheduling Dependencies

A large program is a complex thing, so yet everything that is connected to it.

After initial setup, in a later stage of the program schedule is a driver for everything that is happening on the program.

Starting from the concept of the delivery and dependencies up to the organization.

Let us talk about the concept. I exclude cases we have done this type of program and we know how it works.

For me, I would classify this situation as a project, not a program. We talking here about a completely new initiative.

Are we rolling out first this country or the other one?

Are we going live as a big bang or rather phased approach?

Shall we go pilot implementation, before we commit to the next steps?

These are all the questions that need to be solved at the very beginning.

The concept we take on delivery directly converts into the schedule.

Any later change later is very costly.


"After initial setup, in a later stage of the program schedule is a driver for everything that is happening on the program, including delivery concept, org chart, cost, and resources."


As schedule represents the approach taken it also represents program organization.

Let us say the main activity in the program is a new ERP system we need to deploy globally.

We will see a lot of activities related to the building of the core version of the system as central implementation. We will need to establish a whole org to do this and leadership around these activities.

Then if we roll it out to our divisions, depending on complexity we will need to establish a corresponding organization to take leadership and responsibility for that part of the schedule.

And on and on. Concept drives Schedule drives organization.

Moving on a schedule will determine the cost of the program as resources are concerned.

Getting a stable schedule is a priority at an early stage of the program.

Changing any single piece in it may make all construction of the program fall down.


Challenges of Scheduling

So, what can go wrong with getting schedule stable?

First of all not clearly understood program dependencies may be a major issue.

Let us say with programs there is almost always an end date expectation from sponsors.

And this is not their liking, but they are dependent on other strategic dependencies, like company spinoff, acquisition, or system support end date.

This all makes a very strong expectation on when is the end of our program. Those dates are hardly possible to move as this requires a lot of management effort to rearrange all dominos.

Secondly, programs are typically large and deal with a large part of organizations, countries, suppliers.

Working with all parties concerned to make them aligned to the schedule is a massive challenge.

I remember a case when working as a supplier and we were confronted with a master schedule change. Until we elaborated on an impact the change was not valid anymore and new change had to be discussed.

But first with program management level. Until it came to us, suppliers there was always a risk it will be outdated.


Final Conclusion

In my opinion, getting the schedule finalized at the early stage of the program is essential and a high priority, even at cost of stopping the program and finalizing the schedule first.

The price of not having it agreed at right time could be so high that it risks total program success.

Everybody on the program has to be aligned with the schedule and delivery concept before activities start.

Of course, managing change of schedule as the program runs is fine as long as it does not change completely the concept.

If it does, it is better to stop again and clarify all parts and move on again.






Marek Rudnicki

With over 27 years of experience in new technology companies specialized in professional service and consulting business solutions. Working for different industries like banking, insurance, telecom, e-commerce, manufacturing with a vast track of delivery of data analytics solutions. The key experience is consulting and project delivery - from presale into program management and project portfolio management and practice/portfolio governance. Most of the career working within a multinational environment, managing team, and in a very distributed model organization.