Organizational Development Through Distilled Best Practices
“Pain is temporary. Quitting lasts forever.”
― Lance Armstrong, Every Second Counts
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, organizational development, or organizational transformation are difficult with the profit-driving aspects of the business mounting pressure on disconnected technical focus areas. Each knowledge area or domain, 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.

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