It all starts with infrastructure. Infrastructure allows you to initially start up a business, operate the business, and invest for the future. It includes capital, plant/equipment and human resources but unless customers are identified early on, capital is soon depleted, plant and equipment become obsolete and staff looks elsewhere for employment.
Strategy is the gatekeeper of infrastructure. Strategy development can precede infrastructure building, to an extent, but putting strategy to work requires actual commitment of resources to programs, projects and cases.
In order to for an initiative (a program, a project, a case) to succeed the organization needs plans, budgets and timelines. Any serious deviation from any of these is likely to result in cost/time overruns, and risk of compromising the initiative.
This is where processes come in to provide orchestration for organizational “best practices”. Unfortunately, the nature of some work is such as to require excursions from best practices and, in some situations, the use of ad hoc interventions. Governance is needed at key process points, specifically in the form of rule sets that “ride herd” over both structured process instances and ad-hoc interventions.
Whereas bridging strategy to processes to process execution seems orderly, in real life the people who focus on strategy typically have a top down view whereas those who focus on operations have a bottom up view. Strategists think forests, operational staff thinks trees. The two groups do not always talk to each other.
Everything comes together at program/project/case/organizational Objectives. Objectives bridge the gap between infrastructure and customers.
At first sight, not much new here. Peter Drucker coined the phrase “management by objectives” in 1954 but what we have today that is different are well tested methodologies such as Business Process Management (BPM) and Adaptive Case Management (ACM), plus run time environments that are capable of providing orchestration/decision support and governance in respect of the management of work.
BPM is well suited for managing structured work. ACM is well suited for managing ad hoc work. ACM/BPM outpaces either BPM or ACM alone.
It turns out machines do a pretty good job of handling work. In any case it’s not the work itself that needs managing but rather handoffs across machines.
Knowledge work is no different – knowledge workers generally know what to do and how to do it. They don’t need others breathing down their necks. Here too, it’s handoffs across work that needs managing.
Run time orchestration/governance environments have the ability to deal with when, where and why. It you look under the hood you see software posting carved-up best practices as “steps” to the attention of actors (people or machines) who are available and who have the skills to perform specific work. The environment provides all of the local instructions and forms needed to document the performance of work. Run time resource allocation software levels workflow across actors, actors micro-schedule their tasks, supervisors balance workload across actors.
Now comes the difficult part.
Customer expectations do not derive exclusively from deliverables. A social networking complaint regarding an on-spec deliverable can be as damaging to an organization as a complaint about an off-spec deliverable.
Customers today expect to participate in process improvement initiatives and in respect of custom work, they expect to be able to play an active role in the transformation of inputs to outputs. It follows that run time environments should allow outreach to customers at any stage of the transformation of inputs to outputs.
Processes do not conveniently dovetail to objectives designed to “delight” customers, stakeholders and staff. Program/project/case objective sub-objectives do not conveniently consolidate to overall corporate objectives.
For these reasons, “Figure Of Merit Matrices” can be helpful to assess/track progress toward attainment of objectives. Assessments of progress and projections of availability of deliverables and outcomes cannot be made using simple data consolidations.
A reasonable expectation is deliverables will meet Objectives and Objectives will at all times be supportive of strategy.
This is why Objectives is the meeting place between infrastructure and customers.