"Right Time Delivery"

I feel as if I have coined a two new terms this week, but probably haven't. Either way I think the are worth covering in a blog.

The first term was "right time delivery" and has been  used to head off expected challenge from reviewers of a project brief, the document that outlines the intent and high level approach to a change initiative.

The context is an increasingly common one in financial services, whereby regulators or governments announce and outline intended changes with long timelines and little detail. Increasingly as the issues become global, there is an added dimension. While at the highest level agendas are agreed, when it comes to implementation local politics and legal considerations create inconsistencies that complicate matters for those with international interests.

Now this difficulty is not new, but it is growing. Additionally the resolve of regulators and governments to enforce new demands to announced timetables is much stronger than it was. Previouly ambiguity and uncertainty often led to deferrals and modifications, so adopting a "wait and see" approach was not a bad one. The recent crisises and loss of confidence in financial services has changed that.

As a project or programme manager tasked with delivering solutions and outcomes, one finds oneself in a difficult place. Charged to deliver unclear requirements to dates that must be considered to be firm, with and for an industry that is already stretched and knows that "wait and see" has often been the right response before, how does one create a call to arms?

My response recently has been a pragmatic approach, that has

• Acknowledged the aspects with longer dates AND greatest uncertainty
• Focused on the aspects with nearer dates OR of a scale that need early attention
• Considered the level of risk to the enterprise inherent in each aspect

In outlining an approach and creating an indicative timeline, the questions "why?" and "why not?" have hardly been off my lips. In documenting the results I realised that some reviewers/stakeholders may not understand some elements, particularly why some are pushed right back to published deadlines/milestones and others appear accelerated.

In responding to this I pointed out that this was not a minimalist, "just in time" approach, but rather a "right time" approach where judgement has been applied to the current understanding of requirements and related risks. Readers will know that the need for good judgement is a recurring theme for me so it's inclusion here should be no surprise.

Some may ask why just in time is not the best approach, but this leads on to the next phrase which is "co-operatively compliant". This is a recognition that the organisation needs to create confidence in its regulators, clients and other key stakeholders, that it will be compliant, even if the details are confused or unclear. Planning everything for delivery just in time, ignores the knowledge that "things happen" ie projects encounter unexpected difficulties and delivery is often delayed. As a result a just in time approach can easily be viewed as being reluctant and unco-operative and attract distracting criticism and debate.

I have used co-operatively compliant as a principle supporting decisions made in designing the approach and scheduling aspects of it. So far it seems to be met with a nod of the head, but time will tell.

I wonder if these resonate with anyone else?