Integrated Approach to Organizational Development

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.

The Importance of an Integrate Approach

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.

Processes and Templates

An integrated approach to aligning work should attempt to use the doctrines and best practices of each area. 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

 

Keywords: organizational development, organizational redevelopment, reorganize a company, rapidly mature a company, how to quickly mature a company, capability maturity