An Integrated Approach to Organizational Transformation

By Don Krapohl

www.augmentedintel.com 26 April 2013

 

Your small company is bulging at the seams on its way to mid-size stardom and needs structure to let you reach your next goal.  Rapid organizational maturation is difficult with the profit-driving aspects of the business mounting pressure on disconnected technical focus areas.  Each of these subject areas or domains, such as project management, software development, data analysis, reporting, systems administration, and service desk tier 2/3 may be performed by one or two individuals.  To advance the company must grow into specialization and with that comes the additional problems of aligning work across departments.

Small business transformation often causes significant pain and anxiety and undertaken without seasoned technical leadership can be costly.  As your staff becomes specialized they become increasingly aware of the doctrines and best practices within their discipline and a grass-roots movement to adopt them may begin.  The company benefits from this knowledge but it takes experience to gain the well-rounded vision required to incorporate these bodies of knowledge into a cohesive whole incorporating appropriately-scoped methods that offset their cost.  Frameworks and bodies of knowledge cover the breadth of a field by design and don’t come with decision criteria or context by which to apply them to an enterprise.  To this end there are a small number of cross-supporting practices, which carried out consistently, can provide a lower-risk path to maturity and add an immediate foundation on which to build any size technology organization.

The Capability Pipeline

In an IT engineering and support organization there exist five key domains that can cover products and services from conception to sunset:

Domain

Key Contribution

Key Measures of Maturity

Service Portfolio Management (Portfolio Strategy)

Aligns resources with needs

Financial performance

Change Management

Understands and controls technology changes

Reduction of unplanned changes

Project Management

Oversees the execution of plans

Cost/schedule performance

Software Engineering

Creates and updates software

Code reuse and code rework

IT Operations

Supports existing products and services

Process repeatability

Table 1. The Five Key Capability Domains

As suggested in table 1, patterns of work, measures, motivators, and steps to maturity differ within each area.  IT Operations for example is the core of healthy customer sustainment and is advanced by ensuring each incident and request encountered has an associated Category, Type, and Item in your service desk application to allow continuous movement of issues from customer to issue resolution.

Figure 1. Integrated Workflow Viewpoint

Processes and Templates

Establishing the formal interfaces between groups and processes is vital and serves as a contract and trust-builder.  Effort generally flows from a strategic portfolio initiative into projects for execution to engineering for analysis and build to operations for release and sustainment as demonstrated in Figure 1.  The flow of work can then be re-energized through requests for new features, modification of existing features, or issues with the current product.  The product that moves from one domain to the next will serve as the request for service and the seed of the follow-on processes.   Interaction between departments and functions without formal and recognized triggers to request support result in ad-hoc execution of work with limited visibility and no consistent tie to the organization’s strategic goals.  The symptoms of this are that a limited cadre of people are able to use strength of will to push projects through and constant complaints from the executive ranks that they don’t k now what’s going on.  Interface points create natural firewalls between differing approaches to work and excellent targets for performance measurement.

The Importance of an Integrate Approach

An integrated approach to aligning work should attempt to use the doctrines and best practices of each area.n style='mso-spacerun:yes'>  Table 2 below outlines the high-level steps in moving from conception through support.  The steps proceed from 1 to 13 employing the appropriate framework and using the terminology appropriate to that domain.  For a broader perspective on each element each element is linked to its concept in the authoritative source.

Step

Doctrine

Process Area

Document

Purpose

Who does it

1

ITIL

Portfolio Mgmt.

Change Proposal

Bundle Requests into initiatives

Executive Sponsor

2

 

Service Transition

Approved Change Proposal

Grant and communicate authorization

Change Manager (or Operations Mgr.)

3

PMI

Initiation

Charter/PMP

Establish goals and initial plan for execution

Project Manager

4

 

Execution

WBS & Schedule

Provides a multi-dimensional representation of the elements required to complete the project

Project Manager

5

SDLC

Planning

Requirements

Identify exactly what is required in the product or service

Business Analyst or Developer

6

 

Planning

Interfaces *

Design interfaces – wireframes for user interfaces, application interfaces for services, reports and visualization for reporting

Developer

7

 

Planning

Database Design *

To create a physical and logical database design

Developer or Database Administrator

8

 

Implementation

Work Items *

Breaks the work into small, executable chunks for assignment

Developer

9

 

Implementation

Bugs *

Tracks bugs for fixing and reporting

Developer

10

 

Implementation

Source Code *

Delivers the machine-readable instructions that provide the product or service requested

Developer

11

 

Implementation

Release Package *

Supplies the final product and supporting documentation

Developer

12

ITIL

Service Operation

Category/Type/Item (CTI) classification items

Ensures service supportability through the service desk

Developer or Service Desk Lead

13

 

Service Operation

Operational Run Book

Provides a known plan of action for recurring maintenance tasks

Developer or Operations Manager

*No template available as these documents are technology-specific

 

What Was Left Out, and Why?

ITIL Experts, Project Management Professionals, and Software Engineering Institute fans will immediately point out that the information outlined herein significantly cut their frameworks.  In most transitional organizations there is a broader need for an integrated approach to better practices that expert-level and all-encompassing adoption of each body of knowledge.  The frameworks and bodies of knowledge act as an implied insurance policy reducing the net risk of execution and raising the possibility that a service or product will be executed end-to-end.  Documentation from a business perspective is mostly overhead and a balance must be struck between offsetting risk and unnecessary expenditure.  To that end several significant artifacts were excluded from this process as experience indicates that an interdependent process model will support some elements that are duplicated across domain boundaries.

Information Technology Infrastructure Library (ITIL):

·         Release Management  is left out as it is part of the release package and release SOPs

Project Management Institute (PMI):

In practice only five artifacts always required to execute a project—charter, Project Management Plan (PMP), work breakdown structure (WBS)/schedule, risk register, and issues list. 

 

·         In this approach the charter and project management plan are combined to balance the need for lightweight execution and process scalability.

·         The risk register is not included as risks are included in the charter/PMP and risk management handled indirectly through the bug list.

·         The Issues List in project management is handled by the Software Development Lifecycle’s bug tracking.

Software Development Lifecycle (SDLC)

·         Specifics required of a large-scale effort in which Agile is not selected as the best approach.

Summary

Each domain framework and body of knowledge brings potential value to the maturing organization.  A barrier to adoption is an inability to take each in context and create a cohesive whole that harnesses the productivity and quality gains that make their implementation necessary.  This is a universal problem in the small business transforming rapidly into a larger enterprise.  The model outline above provides a solid foundation on which to build a high-performing and coherent capability pipeline and sustainment operation.

Templates

The templates for each artifact are linked in Table 2 and repeated for convenience below.

Step

Document

Purpose

Other Formats

1

Change Proposal

Bundle Requests into initiatives

OpenOffice format

2

Approved Change Proposal

Grant and communicate authorization

OpenOffice format

3

Charter/PMP

Establish goals and initial plan for execution

OpenOffice format

4

WBS & Schedule

Provides a multi-dimensional representation of the elements required to complete the project

 

5

Requirements

Identify exactly what is required in the product or service

OpenOffice format

12

Category/Type/Item (CTI) classification items

Ensures service supportability through the service desk

OpenOffice format

13

Operational Run Book

Provides a known plan of action for recurring maintenance tasks

OpenOffice format