The concept

A directive approach should not be confused with micro management or a dictatorial mindset. Programmes are too large, too complex and too fluid for such approaches. However, the directive approach does mean accepting that the leadership team hold ultimate accountability for plans, key decisions and critical actions. It is no excuse to say that “people made the wrong decision” or “team Indigo did not deliver”, if this happens it was because the leadership team gave them too much freedom or tasks they were not capable of. The leadership team may be focused on the strategic road-map one day and then a member may be leading the execution of a high risk technical change that evening. Direction can occur at all scales and at all levels of organisation.

Levels of involvement

Levels of supervision cannot and should not be uniform. Critical activities, of whatever scale, that can make or break things demand greater attention than less critical ones, all other things being equal. Approaches are determined on a case by case basis taking into account the nature and potential impact of the task or decision and the extent to which execution teams, outside of the leadership function, have a proven ability to deal with the challenge. The greater the proven ability the lighter touch the hand of the leadership team.

Key Elements

Key elements of direction include:

• Route maps
• Wave based planning
• Command intent
• Objectives and Constraints
• Targeted supervision and intervention

Precision, Clarity and Decisiveness

Precision requires making clear decisions and goal setting based on the content of what is being done and the situation within which it is occurring. Playing “safe” by not deciding and or by being vague to mask a lack of decision is not allowed. Clarity means communicating this consistently and effectively, explaining context as well as the core information. Timely decision making and implementation of decisions is essential, losing days or weeks whilst prevaricating about what to do has destroyed many programmes. Make a decision and learn from it rather than delay.

What is takes

Firstly, though it may sound obvious, the leadership function needs to contain leaders. People who will take decisions and live by the consequences. It is not the domain of people who want to be fully protected with safety blankets of pseudo analysis and caveats. Disciplined risk takers are need. Secondly, the team needs to understand the content of what is being done. Not everyone needs to be an expert in everything but, collectively, the leadership needs the knowledge and experience to understand and, if necessary, oversee the work and how it is approached.

Route Maps

Work needs a route map. A coherent approach to achieving what needs to be done. An approach mapping out a sequence of, increasingly valuable, objectives tied together by a mesh of the significant activities that will move things from one set of objectives to the next. More than a set of milestones and activities on a Gantt chart, the route map defines how the objectives will be measured and what the activities must do. A narrative brings “the story” to life covering both how the work will be done and how the outputs will be used and supported. A well conceived, expressed, validated and communicated a route map provides the solid foundation for the work.

Wave Plans

The route map provides the “big picture” view of what is to be done, but execution requires bottom up delivery focused planning. Pragmatic planning involves planning in layers and doing so in waves. Longer term plans have one level of detail and high uncertainty whilst medium and shorter term plans add increasing detail and, hopefully, have decreasing uncertainty. Layering and the horizons of plans at each layer will vary from cases to case but the principle needs to be adhered to.

The planning matrix builds from the plans prepared and owned by delivery streams that show what they commit to do. At any level the aggregate effect of these plans creates the overall programme picture that can be validated against the expectations of the parent layers and the road map. When it comes to execution plans, separate plans owned by individual units are essential, monolithic centrally maintained plans are a no-no.

Tasking

Delivery units and teams need to be tasked with the work they have to do to support the route map. Tasking flows into the planning and execution space, A layered wave approach to tasking links to a similar planning approach. High level tasking may run out for one duration, where-as for more detailed tasking, where it is appropriate, the time horizon will generally be nearer. Effective tasking is essential, there should be a dialogue to ensure all units have an understanding of their own and of other units tasks. Effective tasking needs clear communication of Intent, Objectives and Constraints.

Intent

Intent conveys the big picture of what it to be done and how work streams interact to achieve it. It describes the what the next phase of the campaign in more detail than the route map and in more concrete terms. It may contain specific dates and times, it may identify people, places and data, it integrates the approach into the here and now.

Objectives

Each work stream needs to be given concrete objective to achieve. They also need to know when, in time or sequence or both, objectives need to be achieved to support the overall scheme of activity. Meaningful objectives are rarely binary and so measures and evaluation criteria should be given. Surprise scoring system applied retrospectively should be avoided.

Constraints

Any exceptional restrictions on the way things are to be done need to be explicitly conveyed. Other than honouring these constraints, the delivery planning process should be free to plan the work in any way that fits the intent and objectives that works within their normal operating constraints.

The Tasking Process

Holistic, rather than piecemeal, communication should form the basis of tasking. A single document, shared with all, should task all teams. A single briefing, with questions and answers, should be used as a formal tasking event for all teams. Playback from the teams to demonstrate how they have interpreted the input should be part of the process.

Helping Hands

A tenet of this approach is that you do not leave critical work to be planned and executed in “isolation” by teams or individuals who do not have the capability needed to do this with an acceptable level of risk.

Hopefully, most things a team is tasked with they will be fully capable of planning and executing without issue. Some things may be more challenging for them but, if they go off track, any impacts can be addressed after they materialise. However prevention rather than cure is necessary where the consequences of going off track are high and hard to contain and the ability of the team is in question.

The leadership team must have the measure of each unit and knows what they are capable of and where they will need support. The nature and extent of this support will not be uniform, it should be targeted, based on the level of risk. The level of risk that emerges from the combination of capability gap and downstream impacts.

How to assist

Ideally, assistance should not bypass the normal Tasking, Planning, Execution flow. It should not cause work for the team in question to be decomposed into smaller, more numerous, items of work. Tasking should processed as if the delivery team has the competency to handle the work on its own. Then how should the problem be addressed?

Aid should be provided within the planning and execution process that kicks in once the work has been allocated. A member of the leadership team should “join the team” to get them over the hurdle. Whether they guide, supervise or take charge will be situation dependent. The aim should be to build the plan and execute the plan successfully so that, outside of the team, the work looks like any other piece of work being delivered by any other team.

Real assistance

To be clear, assistance does not just mean content agnostic management of work, dropping in a planner or a project manager. It means assisting with the crux of the issue. This could need a multitude of things. Examples in the delivery domain include establishing a position and negotiating its acceptance, working out how to do a phased delivery, planning around constraints and the daily tracking of work of individuals. Items with a more technical focus could include validating a deployment process is “safe”, rationalisation of designs or working through a complex problem.

No excuses

To restate the underlying principle here, the leadership team need to ensure that tasked worked can be planned and executed “safely”, that is without risking the programme. Where the units receiving the task need help to ensure this then the leadership team must provide it.