It's long been held that good people make for a good organization. We often hear anecdotes about how "our people make us great," but greatness has as much to do with organizational processes and structures as with staff talent. Effective organizations amplify the talents and capabilities of individuals and teams, while ineffective organizations mute them.
In my role as manager of the Network Operations Center at the University of Wisconsin–Whitewater, I deal primarily with technology infrastructure. I manage a group of experienced, talented professionals who believe strongly in what we do. My staff work hard and often invest tremendous amounts of time and energy in getting infrastructure projects done.
Despite this, we often struggle to produce consistent results. The roles and organizational structures necessary for good project management have not been well defined. Often, the outcome of a project depends more on the personal perspectives and actions of the person doing the work than on organizational processes or standards.
A number of problems result from this lack of structure. Senior staff, already fully committed providing full vertical support, cannot engage in new work. Best practices remain trapped in silos instead of being applied generally. Management has little awareness of and involvement in operational practices and day-to-day decision making. Lastly, the user perspective has often been left out of strategic direction setting, leading us to treat every problem as a pure technology problem.
As an infrastructure provider, I often see situations where the absence of a technology infrastructure prevents customers from achieving their potential. In a very real way, the absence of an organizational infrastructure to support effective processes limited my organization in the same way.
Measuring Organizational Maturity
The Capability Maturity Model1 (CMM), a software development model from Carnegie Mellon's Software Engineering Institute, provides a mechanism for measuring the maturity of an organization's process infrastructure. While the CMM focuses on software development processes, the key concepts are portable across many types of processes.
The CMM defines five levels of organizational maturity. Each level encompasses several key process areas that, when mastered, constitute achievement of that level. The levels are progressive, and a maturing organization can expect to go through each one.
Level 1—Initial
Level 1 organizations are ad hoc and chaotic. Successes result mainly from personal sacrifices and heroic efforts. The organization nevertheless succeeds but frequently exceeds budgets and misses deadlines. Level 1 organizations tend to over commit, abandon their processes in times of crisis, and have trouble repeating past successes.
Level 2—Repeatable
Level 2 organizations have processes in place for requirements management, project planning, project tracking and oversight, quality assurance, and configuration management. Level 2 organizations can repeat their successes, and project status is visible to management at defined points (milestones, for example).
Level 3—Defined
Level 3 organizations have processes that are well characterized and understood. Projects establish processes based on an organizational set of standards. Some effort is made to set objectives for processes and measure progress toward those objectives.
Level 4—Managed
In a Level 4 organization, process management is quantitative. Specific metrics are set for processes, and process effectiveness is judged relative to metrics.
Level 5—Optimizing
The Level 5 organization represents process nirvana. Level 5 organizations establish and grow processes for defect prevention and change management.
Conventional wisdom tells us that most organizations start their process improvement efforts at Level 1. Tom Schorsch of the U.S. Air Force Academy presented a mildly tongue-in-cheek model of "Organizational Immaturity,"2 recognizing that organizations can do quite a bit worse than ad hoc and chaotic behavior. To that end, Schorsch defined an additional four layers.
Level 0—Negligent
The negligent organization is largely indifferent to project management principles. Improvement efforts tend to fall victim to organizational inertia. Improvement efforts start and then fade away. Successes may be claimed, but nothing actually changes.
Level -1—Obstructive
Obstructive organizations have processes, but they're rigid and ritualistic. In obstructive organizations, processes exist largely to obscure the work and excuse the outcome.
Level -2—Contemptuous
Contemptuous organizations completely reject any efforts at improvement. Time spent "improving" is seen as a distraction from time spent "working."
Level -3—Undermining
The undermining organization actively works to discredit peer institutions' efforts at improvement. Undermining organizations highlight the faults and failures of other organizations as evidence that improvement efforts are a foolish waste of time.
Where We Started
An interesting characteristic of organizational benchmarking is that different parts of an organization will occupy different levels at different times. In 2005, as my organization began to introduce some of these concepts, the majority of the organization was at the initial level. A few areas might have qualified as repeatable and a few others definitely qualified as negligent, but the organization's center of gravity fell within the initial level. The variation was interesting, however, as some portions of the organization were impatient for process improvement while others seemed quite reluctant.
Our initial assessment resulted from a simple and informal comparison of management and staff perspectives against the characteristics described in each of the CMM levels. While we probably should have employed a more scientific approach to benchmarking, this method gave us a good sense of how we perceived ourselves as an organization. (See Figure 1.)
Click image for larger view.
Strategizing for Improvement
Our management team had several meetings internally and with staff to discuss problematic areas that needed improvement. In looking at our major problems, several areas of organizational weakness surfaced repeatedly:
- Committing ourselves to work with unclear scope or boundaries, leading to over commitment at all levels
- Lack of clarity in decision-making processes, leading to frustration, inconsistent communication, and decisions frequently at odds with organizational goals and directions
- Absence of a standard or venue for quality control, leading to inconsistent levels of quality and differing opinions about "sufficient" quality control
- Failure of management awareness of and involvement in projects and processes, leading to many after-the-fact disagreements about expected outcomes
These problem areas fit well with the description of a CMM Level 1 organization (chaotic and over committed). We lacked some of the key process areas identified in CMM Level 2, things like requirements management, project planning, project tracking and oversight, quality assurance, and configuration management. Interestingly, we did not set out to address each of these areas methodically, but the solutions we identified encompassed all of them.
Implementing Our Solutions
To address our problems with over commitment, we instituted a formal methodology for project startup. This methodology put in place a body of documentation that each project was required to produce prior to approval. Key pieces of data collected during project startup were:
- Scope—defining what the project will (and, especially, will not) do
- Requirements—what's needed to call the project a success
- Resources—what we expect to commit to the project
- Plan—how we intend to complete the project, including milestones we can use to measure progress
To provide clear decision making and assist in quality control, we chartered a technology infrastructure oversight group and gave it responsibility for defining organizational standards and ensuring consistency with them. This group consisted of lead technologists from each of our major infrastructure areas (server platforms, networking, and security) and our first level of management responsible for infrastructure services. Other IT managers are frequently invited to participate as topics come up that affect their areas.
This group has effectively provided a forum for reviewing possible infrastructure decisions and directions. Having a wide technical perspective ensures consideration of all angles of a proposal, and having a group that's charged with defining organizational standards gives us a clear path for decision making that involves both technical staff and IT management. While not everyone agrees with each decision that this group makes, staff for the most part accept the group's work and welcome a defined process for making decisions.
To provide management awareness of project status, we've deployed a time-tracking system3 for staff to record time and status on projects. We opted for an externally hosted system to minimize the initial cost and footprint required to get the system up and running. This has served us well for our pilot deployment, but we will probably outgrow this model in the near future.
Our time-tracking system allows us to enter project and task information defined during the project start-up phase, assign staff, and permit staff the ability to record time against their projects. In addition to projects, we have defined tasks for ongoing support and maintenance. This allows us to understand the staff cost of support versus new project work and to better understand our true capacity to take on new work.
Many of our staff were as surprised as we were to see how much time was devoted to support tasks. This difference between perceived time for support and actual time is a principal source of over commitment. With data about true support requirements, we can plan more realistically.
Our staff had a mixed reaction to the time-tracking system. Most see its benefits and appreciate our trying to plan realistically, but they are also concerned about excessive focus on time spent as opposed to results achieved. Understandably, staff don't want to be put under a microscope.
To gain a better understanding of our commitments and capabilities as an IT organization, we are working on a system to assist in project portfolio management.4 This effort looks at resource commitments across all of our projects. Our primary goal with this effort is to plan cooperatively with our campus customers, ensuring that we can schedule and prioritize projects appropriately without over committing.
Our Results to Date
After approximately 12 months of concerted effort, we estimate that our organizational center of gravity has moved roughly half a level, to mastery of most (but not all) of the key process areas of Level 2 in the CMM. (See Figure 2.) This assessment is based again on simple and informal comparison of management and staff perspectives against the characteristics described in each of the CMM levels. As we progress in sophistication, we hope to incorporate more data-driven metrics to help us gauge our effectiveness.
Click image for larger view.
While this may seem like a very small movement, the benefits have been tangible. Projects are more clearly defined, and both management and staff are more careful to define requirements and scope prior to engaging the organization in new work. We are working more closely with our customers to set expectations and plan cooperatively when starting projects. Roles and responsibilities are more clearly understood, and we have a better grasp of organizational capability and ability to commit to new work.
What We Learned
A few notable lessons stood out from this work. First, it's important to recognize that different parts of your organization are at different levels of readiness for process improvement. Some parts may be desperate for more structure and definition, while others will only go kicking and screaming. You'll need to manage each of these groups as you guide your organization through these changes.
Our organization, for example, had only a few key staff members who were interested in seeing us do a better job of project management. Most were indifferent although not hostile to the concept. A few were quite resistant to any form of structure. Since this was primarily a management initiative, we managers needed to take the lead in describing, convincing, directing, and ensuring that new processes were followed consistently. Given the number of staff who were indifferent to the initiative, it was important to positively reinforce the processes so that successes were rewarded. We did not do as good a job here as we should have, and several staff members who could have been advocates for us instead soured on the process.
Second, it's important to recognize that process change is still change—it can be threatening and upsetting. It's important to handle any change with compassion and respect. You can't reasonably expect complete buy-in, but you'll earn more cooperation and trust if you approach the problem openly and respectfully.
Since a key part of process and project awareness is organizational visibility, staff may feel that the organization (by which I mean management) is intruding on what used to be private space. Some staff may draw inferences about lack of trust, suspicion, and other negative motivations. We tried to address these issues by sharing our reasoning for the changes and by explaining how time and project information would be used. This addressed most people's concerns, but not all.
Third, it's difficult to manage process improvements for a single part of a larger organization. While we worked to enact these changes in our IT organization, we also engaged in a number of campus projects that were not using these methodologies. This led to confusion in when and how our staff should employ particular methodologies and frustration when customers didn't embrace the same principles that we were asking our staff to embrace.
On many of these projects we attempted to employ project management principles such as scope definition and requirements definition for our parts of the project. We had limited success with this in most cases, as scope and requirements management require commitment from both the customer and supplier. In these cases, we did our best to highlight the problems caused by the absence of project management and the benefits that active project management would have provided, and we sought commitment that the next major campus project would address some of these key areas. Rather than pushing to change methodologies on projects already in progress, we focused on building awareness and consensus to address the next project in a more orderly fashion. Often, this consensus came in project postmortem meetings and after-action review sessions.
Lastly, it's very important to be clear in your expectations and consistent in your reinforcement. Some staff members were new to the concepts of documenting requirements and deliverables and putting together project plans, and they needed a lot of guidance and feedback during their first attempts. As you enact change in your organization, you should be prepared to support your staff and provide feedback and encouragement as they adopt new methodologies.
A project-management or time-tracking initiative is not the kind of initiative that excites or inspires most staff. Such an initiative won't act as its own reward, so it's important to ensure that adequate encouragements and rewards are in place.
In Summary
Process improvement and organizational development go hand-in-hand. Building out your organizational process infrastructure will provide the tools necessary to build and maintain effective processes. It takes time, effort, and persistence to get through the initial stages, but the foundational steps of process awareness set the stage for later achievements.
This is hard work, and much of it will fall on the management team. Much like establishing a technical infrastructure, however, it's necessary to enable your organization to reach its potential. By doing this work, you'll become process-savvy and ensure that your organization amplifies rather than mutes the talents of your individuals and teams.