In medium to large organisations the pipeline for new projects is often large and business owners battle amongst themselves to grab budgets and ensure priority calls go their way. Budgets are not unlimited and resources cannot always be scaled up to accelerate work products creation (in software development projects at least – so even if a project has its budget secured, the next hurdle is securing resources to deliver the objectives at a suitable time (i.e., very soon).
IT departments often are confronted with many part of the business pushing for their work to be done first. You would think that IT would be courted by business owners for favours but often this more a blame game with escalation to the top. This consumes resources and is not a healthy start for collaborative work.
Part of the problem is expectations management. Projects begin as ideas, as those ideas mature, the cost to deliver and timescale start to materialise in the owner’s mind and often this is crystallised and assumed as reality. When IT end up being fully engaged and discover more of the requirements then the picture drawn up is often different that the crystallised picture. Disappointment occur.
The other problem is managing resources constraints, even if a project is funded there are other projects inflight and the newly approved project might face resources shortfall, leading to a delayed start date. Again a source of disappointment.
There are solutions to this, it helps for example to build visibility very early of available capacity and potential bottlenecks. Capacity should never come as a surprise to anybody in the organisation. Having a visualised and simple roadmap effectively communicated throughout the organisation is a good start.
Second, manage expectations. Often project spend a lot of time at business case and requirements level, if delays occur there then resources might have gone (taken by another project) and timescale won’t look good by the double effect of late requirements and less resources available. So capacity updates should be regular once the project has started.
These are usual symptoms of a “Push” mode, where projects are pushed towards delivery. Available resources are not so much considered in this mode. Forecast of resources availability are built and planning created based on those forecast but dealing with actuals, what's happening on the ground, means having to adjust project plans to match the actual capacity. These replanning are not out of the ordinary but if you consider the number of projects this can require significant negotiations and work with other project teams and business owners. Back to square one.
An alternative would be a “Pull” mode where the delivery teams pull work when they have capacity to deliver. One might consider that even in a "Push" mode we are in effect in a "Pull": in the end the capacity level dictate the work you can do. In a "Pull" mode the key change is that this is accepted mode of operation and the product development lifecycle is built on this, so in the end there is less surprises, less management time spent on managing expectations and less stress and disruption to the teams.
A hard part remain: ensuring the business as a whole decides which project comes next for delivery.