Delivery Management (DM)

Delivery Management is perhaps the most transparent of the VOF areas. You must be able to deliver your core product or service, with excellence, in a cost effective manner. If you can’t deliver at the same or higher level than your internal or external competition, there will often be undesirable changes. Conversely, those that develop high performing organizations who can consistently produce at or above expectations are invariably rewarded for their consistency. When it comes to building a highly performant delivery organization, the challenges often fall into four predictable areas.

The Nature of the Challenge

There are a wide variety of issues when dealing with Delivery Management, but most scenarios involve at least some of the following aspects:

  1. Estimation and Budgeting — Estimating is an absolutely essential skill. If you can’t estimate effectively you can’t operate. If your organization tends to estimate too high, you will build too much capacity and will not be cost effective. If you estimate too low, you will not have the necessary resources and will ultimately not deliver at the required level of quality or speed. Ironically, estimation as an organizational core competence is as important as it is rare.
  2. Manage your Productivity Busters — Every organization has productivity busters. These are the eminently reasonable behaviors at the individual level, that sneak into our collective work lives. What seems like a reasonable accommodation at the individual level, when institutionalized become a recipe for mediocrity. Examples of productivity busters are: excessive reprioritization of work, rework, chronic knowledge worker interruptions, inefficient status management and reporting, inefficient review and approval cycles, lack of accountability, confusion about roles and responsibilities, and poor communication.
  3. Theory of Constraints — Every organization or process has constraints. The TOC says that if you are going to increase through-put you must be able to understand which is the weakest link in your process and improve capacity and capability against that function. This will inevitably move the constraint to somewhere else, where you can address it again. If you are going to be aggressive about improving throughput, you should be relentless about attacking your current constraints.
  4. Quality — Far too many organizations have the same definition of Quality that the Supreme Court did for pornography: we know it when we see it.. A high performing organization needs to formally define quality and then look for ways to ensure quality as early in the process as possible.

Considerations for the Solutions Architect

PEOPLE CHALLENGES

Delivery management is perhaps the most difficult of the various VOF areas to change because it has to do with how people behave, believe and work on a regular basis. Changes to such fundamental elements will be inherently challenging. In order to begin to drive behavioral change you must define what behavior you want, what data you will use to know that those behaviors are or are not happening, and then make tactical decision on that data. People respect what you inspect, and if you are not making decisions or driving for change over a sustained period, people will quickly conclude this is the next idea-du-jour.

PROCESS CHALLENGES

One of the issues with delivery management is that people tend to overuse process definition as a solution. The thinking being that if we architect the optimal process things will naturally improve. Unfortunately, building a process and having a process are not the same thing. Building a process usually involves a Visio diagram and a work package that most any competent professional can complete. Having a process involves socializing that process at a level where everyone in the team knows it, and lives it. Value is created at the moment you have a good process, and yet far too many people stop at just designing them.

PLATFORM CHALLENGES

Systems need to support decisions, which in turn helps you shape behavior and drive change. Far too many system implementations begin with “standardized” reporting libraries. The problem is that many of these reports are architected by people who understand the data, but not the ,problem you are trying to solve, the behavior you are trying to change, or the idea you are trying to socialize. In this case these canned reports often become useless data. When evaluating your platform, or looking at a new one, ask yourself if the data provided is going to help you drive, change, solve or socialize. If you are not crystal clear on why and how to answer in the affirmative, it may be better to move on.