In the practice of software development, whether performed as an organization's primary business function or performed in support of the business of an organization, there are two process models that are frequently part of the organization's development environment. First is project management or, from an organizational view, management by projects. This distinction is made to highlight that the practice of project management, as described and codified the Project Management Institute in A Guide to the Project Management Body of Knowledge (PMBOK® Guide), is primarily focused on the individual project and the processes and knowledge areas that apply to successful management of a project.
The second area of interest in many organizations is the Capability Maturity Model for Software (SW-CMM.) This model describes key practices and activities for software development that points the way to an increased level of quality, productivity and, it is hoped, decreased cost for development.
This discussion will attempt to synthesize certain concepts from both management by projects and the SW-CMM and propose a management by projects framework, which can be used to appropriately tailor and interpret the SW-CMM in light of an organization's development structure, environment and culture.
The Capability Maturity Model for Software (SW-CMM)
The Software Engineering Institute (SEI) at Carnegie Mellon University has created a widely accepted model that acts as a basis for organizational software development improvement. Called the Capability Maturity Model for Software (SW-CMM), this model has been embraced by many organizations who wish to improve their software development results as measured by any of the most commonly used metrics; cost, quality, timeliness, etc.
The SW-CMM charts a path for development organizations to gain control of the disparate processes that contribute to the development and delivery of software based products or systems and for institutionalization of the methodology, providing ways for organizations to continuously assess their adherence to best practice.
The Need to Tailor and Interpret the SW-CMM
Adoption of the SW-CMM and progression through its five levels of maturity requires a significant resource and belief system commitment on the part of an organization. The SW-CMM was developed in conjunction with the Department of Defense and is a methodology targeted for a rather specific type of organization: “contractors concerned with the development of large, software-intensive critical systems” (Ginsburg 1995, 1). Despite this, the SW-CMM has found a home in many non-government businesses and organizations and “... serves as the foundation for a major portion of the process improvement being undertaken in the software industry” (Ginsburg 1995,1).
That being said, organizations not similar to the target organization for the SW-CMM must fully understand all aspects of the model but recognize the “... need to interpret and/or tailor the key practices before they can be applied” (Ginsburg 1995,2). It is the nature of the organization's development environment that most authors point to when the issue of tailoring the SW-CMM is discussed. The complexity of such environments is often measured in terms of the number and variety of software development projects an organization may have underway at one time, especially in organizations where development is in support of the business and not the business.
In such an environment, development projects may range from strategic projects, which will have a significant impact on the future of the company even if they fail, to those small and medium projects that are part of the daily operation of business information systems. At the strategic project end of this scale, software projects may be part of a larger enterprise effort with the software development activity concerned with what the SW-CMM refers to as requirements allocated to software. At the other end of the scale are what some might consider informal tasks but involve repetitive maintenance activity which, because they contain some element of uniqueness during each repetition, are managed as small but distinct projects. The issue in such heterogeneous project environments is not if tailoring the SW-CMM is necessary but rather how many different interpretations may be necessary. “Each organization needs to balance a ‘one-size-fits-all’ approach against maintaining several ‘custom-fit’ processes” (Ginsburg 1995,28).
It is not a trivial task.An organization committed to the principles of the SW-CMM will invest a significant amount of time and effort in reaching their target maturity level. Additionally, achievement of a specific SW-CMM level of maturity and the attendant benefits becomes a part of the corporate culture. Those benefits and supporting processes are often deeply internalized by many members of such organizations. Tailoring may be viewed, by those committed to the SW-CMM ideal, as a retreat from the perceived inviolability of this model.
If one explores the development and evolution of the SW-CMM, it will be seen that the Software Engineering Institute not only understands the need to tailor and interpret but also includes specific discussion of tailoring and interpreting the key practices of the SW-CMM in many of its publications on the subject (Paulk 1993). This activity is not a step back but a natural, indeed, necessary activity for the majority of organizations.
The SW-CMM and Project Management
The SW-CMM recognizes the important role of project management in software development.“At Level 2, the CMM emphasis is on managing software projects”(Paulk 1999,6).In fact, the use of project management is the development approach assumed throughout the SW-CMM.It repeatedly refers to activities in the context of being project activities.“The key process areas at Level 2 focus on the software projects concerns related to establishing basic project management controls” (Paulk 1993, O-20).At Level 3, the focus turns to development of an Organization's Standard Software Process (OSSP), which in turn is tailored to define “(t)he project's defined software process…to fit the specific characteristics of the project” (Paulk 1993, O-50).
In some way then an organization, as it moves from Level 2 to Level 3, must not only have a means and structure for tailoring the SW-CMM but for creating subsets of the resultant standard software process to be used by the multiple projects many organizations must manage.
Project Portfolio Management
Organizations are discovering that commitment to the PMBOK® Guide and the numerous training and educational resources which draw on the PMBOK® Guide and other project management references can result in well-versed project management professionals. These same professionals may quickly find themselves stifled by a lack of organizational structure and paradigm that supports effective project management. Recognizing they are not getting value for their project management training dollar and not achieving the benefits expected from project management practice, organizations are increasingly turning to concepts and processes for managing the universe of projects within the organization. By doing this they hope to better leverage the skills of their project staffs and gain greater management control over the resources necessary to accomplish all projects.
In the organizational practice of project management, the concept of project portfolio management is gaining increasing acceptance. This concept provides a framework for identification, analysis, prioritization, and initiation of those projects best aligned with enterprise objectives and resources. A relatively recent development, this approach is often misunderstood because of how an organization defines its project portfolio. “Currently there exists a general philosophy that all projects under way make up the project portfolio. Unfortunately, a group of projects does not make up a portfolio, it is simply a group of projects, consuming time and resources”(Dye 2000, 1). The real value of project portfolio management is bringing some discipline and oversight into the creation of this “group of projects” so that the time and resources they consume can be anticipated, prioritized, or in some cases, withheld for other uses.
Many discussions of project portfolio management give the perception there is one organizational portfolio. Certainly, in some organizations, the discipline of portfolio management is applied to the most potentially significant enterprise efforts, those that can range from the “bet the company” type to key tactical projects designed to support, extend or maintain strategic objectives and plans. Often overlooked but consuming some of the same resources needed in the more gilded portfolio projects are those “business as usual” activities, which can be of significant scope and complexity but fall into the category of normal business activity and operational necessity. Several project portfolios may exist in reality, the enterprise portfolio and the often less structured groups of projects created by individual business units. These other groups or portfolios, although perhaps not as visible to senior management as the enterprise portfolio, may be of great importance to the chartering business unit and, ultimately of some importance to the whole enterprise.
A weakness in current literature pertaining to project portfolios is a lack of discussion of management of portfolio execution. Even the recognition of the concept of Project Portfolio Management in the 2000 version of the PMBOK® Guide emphasizes the selection and support of project investments with virtually no connection to the practice of project management of the portfolio (PMBOK® Guide 2000). Once the project portfolio, or perhaps portfolios, has been identified and authorized resources with which to proceed, it would appear the intent is to fall back to the practice of project management on a project-by-project basis. The coherence gained by dealing with a portfolio of projects can easily be lost when management of day-to-day execution is divided between a number of project teams. If this is the case, issues of cost or other resource variance, if not dealt with in the same manner as the creation of the project portfolio, will quickly erode whatever benefit was anticipated from the initial application of portfolio management activity.
Should there be one high visibility enterprise portfolio and other less visible pseudo-portfolios, as previously discussed, the impact and costs of not having strong portfolio management implementation discipline for all portfolios may be even greater.
Some may point to the establishment of a Project Management Office (PMO) as a solution to the issue of coordination or even some form of universal control over all projects within an organization. In practice, a PMO often functions as the coordination point of organizational project support in the form of project management standards, project team training, and management and status reporting. There may even be a more direct role for some PMOs in the day-to-day management of certain projects or perhaps that enterprise project portfolio, which is of particular concern to senior management.
Even in a direct role, there are two potential areas of concern. First, the “control” of a PMO over a group of projects does not replace the project managers of the individual projects but evolves into an additional line of reporting for the project managers. It becomes more “over-the-shoulder” control than first line responsibility. Second, even a PMO with an excellent grasp of the enterprise portfolio may be unaware or unconcerned about the projects not bounded within this gilded portfolio but consuming important organizational resources, nonetheless. PMO decisions may then be suboptimal with unanticipated effects on these other less visible but still important projects.
The Project Pipeline
There is a concept for project portfolio management that does concentrate on managing implementation rather than just initiation. It is called the Project Pipeline. I was introduced to this concept while attending a PMI seminar in 2000. The seminar was “Sponsoring Multiple Project Success” and was developed by Plan Tech Incorporated. Basically, it extends the initiation activity of portfolio management through an enterprise process akin to the management of products in a fluid pipeline system.
There are three key components of the pipeline analogy:
1. The entry point, which is the selection, screening, and chartering process and equates very well to the discussion of project portfolio management as usually practiced in organizations
2. The pipe, which corresponds to the project environment boundary
3. The pipe diameter, which represents the organization's resource capacity (Plan Tech 2000).
Another important aspect of the pipeline analogy is the issue of flow and what influences the type of flow present in a pipe. The goal is smooth or laminar flow in both the fluid and project pipe. Those environmental factors, which can disrupt a smooth flow, are areas of concern to pipeline management. To illustrate, let's return to an issue previously discussed.
We have envisioned a situation where project portfolio management is focused on the key strategic and tactical enterprise projects. In this situation, certain projects or groups of projects that contribute to the success of the organization and consume resources are overlooked. Some of these same resources may be needed and earmarked for implementation of the enterprise project portfolio. As we mentioned, the pipe diameter represents the organization's resource capacity. In the best case, the enterprise portfolio is sized to the perceived diameter of the project pipeline and takes into account some recognition of the projects that are not included in the enterprise portfolio. This recognition may be an assumption that reports to management identifying resources available for portfolio work have been reduced by individual business units based on their understanding of their own internal project needs, however imperfect that may be.
In the worst case, the enterprise portfolio resource requirements alone are viewed by senior management as defining the organization's resource capacity and thus the pipeline diameter. In this case, those unrecognized but nevertheless real projects are being forced into an inadequately sized pipeline. Increasing the volume carrying capacity in a pipe of set diameter requires increased pressure and, for an organization, this increased resource pressure can be equated to increased risk to the organization. Alternatively, a drain of pipeline resources for the implementation of non-portfolio projects can be viewed as a narrowing of or obstruction in the pipeline resulting in reduced flow of project work products through the pipeline leading to increased schedule and cost variance.
Overall, the pipeline model provides a good framework for the exercise of management throughout the implementation cycle of the projects flowing through the pipeline. The specific management methods for project flow management are interesting and provide a rich source for further investigation but are outside the scope of this paper.
The Existence of Multiple Project Pipelines
Like the singular focus of the PMBOK® Guide and the oft-limited scope of the initiation processes of project portfolio management, even the project pipeline model can be limited in its attempt to provide a management structure for the multiple project problem. Discussion of the model describes an organizational project pipeline. This may be fine for academic discussion of the methodology but does it recognize more “real-world” structures? As we have discussed, there can be multiple project portfolios, unofficial as some of them may be, so it follows that there will be a similar multiple portfolio pipeline situation. One can only hope these multiple pipes are all flowing toward organizational success.
The Project Conduit
In some applications, multiple lines or pipes of related or disparate function may be encased in a single container sometimes called a conduit. I will adopt the term Project Conduit as a model for the situation just described—a collection of multiple project portfolio pipelines within an organization. Extending the project pipeline components to the Conduit, we have the Conduit itself defining the organizational project environment, the diameter of the Conduit defining the organization's resource capacity. The pipelines within the Conduit are the individual project portfolios’ environment boundary with the diameter of each pipeline defining that portfolio's resource capacity.
When developing the Project Conduit model, I was faced with the need to explain the volume within the Conduit not occupied by project pipelines. It occurs that this “empty” space is actually an accurate representation of the non-specific project, and sometimes non-project related activity that occurs in organizations and is often difficult to manage or even conceptualize. If the Conduit itself represents the organization's environment and the Conduit diameter the organization's resource capacity, we can view the “empty” space as representing activity that is not project or even project management related. This includes such things as administrative duties not related to any specific project or even project management in general, project and non-project related training time and vacation/lost time. In general, it represents that host of activities that are essential to the operation of a business organization but can be lost in an overall scheme of resource management which is project focused. Representing them in the Project Conduit serves as a reminder of the activity tradeoffs that may be necessary to support increased project resource needs.
The Project Conduit as a Framework for Tailoring the SW-CMM
It is now time to return to the question that closed the discussion of tailoring the Capability Maturity Model for Software. Specifically, how does an organization tailor their overall processes for each project type or, in this case, portfolio type? “For example, many OSSPs are written assuming a full development life cycle, and many small and maintenance projects may have difficulty in translating all the roles to their specific needs” (Ginsburg 1995, 30). Is there a framework for tailoring the SWCMM to fit a specific organization's development needs and structure? The Project Conduit offers a possible answer. It provides a structure for recognizing and managing multiple projects with differing development needs, environments and resources while still providing some overall discipline to ensure that all projects, however large or small, are directed toward the organization's ultimate objectives.
In our discussion of the SW-CMM, the project focus of Level 2, the issue of an Organization Standard Software Process and the development of a Project Standard Software Process based on the OSSP at Level 3, was highlighted. Suppose we view the Project Conduit (i.e., the overall organization environment), as including the Key Process Areas (KPA) of CMM Level 2 which are project management controls and those Key Process Areas of CMM Level 3 related to organizational issues especially the OSSP. For example, the six Key Process Areas for Level 2, Requirements Management, Software Project Planning, Software Configuration Management, Project Tracking and Oversight, Software Quality Assurance and Software Subcontractor Management would be specifically defined for the organization as a whole. If the organization is moving to Level 3, the specific definition of the Level 3 KPAs are added to this environment. In effect, the Project Conduit, which equates to the organization environment, is the OSSP. Importantly, the SW-CMM component of the Project Conduit must include specific guidelines describing how the OSSP is to evolve into a Project Portfolio Standard Software Process for the different portfolio pipelines within the Project Conduit. To create these guidelines, “some of the important areas to address…include similarities and differences between the organizational structure implied by the OSSP and the project's structure
• Customer relationships and requirements
• Degree of formality, frequency, granularity, and scope desired for the project in general
• The specific business goals and needs to be addressed by the project
• The current process capability of the organization and the desired process capability of the project” (Ginsburg 1995, 30).
Using a Project Portfolio Standard Software Process rather than a Project Standard Software Process is a basic premise of the discussion. To understand the approach, in the previous quote from Ginsburg, substitute the words “project portfolio” for the word “project.” The issue of having a surfeit of individual project standard software processes is addressed by defining a standard process for a group of projects within a single portfolio pipeline with the association of the projects based on some set of common or applicable attribute(s).
Within the Project Conduit, the individual portfolio pipelines can be defined and differentiated in a number of ways based on, as with interpretation of the SW-CMM, organizational needs and structure. Attributes used for differentiation can include project size, system environment, resources utilized (particularly human and specific systems resources), business group sponsorship, time boxes, project manager/team responsibility or combinations of these and others.
However the differentiation is done, establishing the Project Portfolio Standard Software Process involves defining the specific provisions/modifications of the OSSP applicable to the portfolio pipeline. For example, Software Project Planning could be accomplished with a single project plan for the entire pipeline containing those elements as specified in the OSSP. The portfolio pipeline software plan could provide for simple individual project specific attachments that primarily contain project identification information. This makes the portfolio project plan a single reference for basic information about all projects in the portfolio pipeline. A single schedule for the portfolio pipeline would contain information on all projects in the portfolio, some of which might be common given the attributes used to group the projects. A combined schedule, even if updated by multiple project managers, would provide an excellent tool for management oversight at the portfolio level perhaps by a Project Management Office.
Interpreting/tailoring activities using the Project Conduit will often take the form of reducing the scope of or eliminating certain KPAs. The most common example is the elimination of Software Subcontractor Management activities in projects that do not use subcontractors for development. Situations can be envisioned where significant parts of other KPAs can be scaled back or eliminated. This is especially true for internal development organization projects concerned with maintenance and upgrade activity. Requirements Management, Software Project Planning and Project Tracking and Oversight could potentially be scaled to minimal levels consistent with the risk associated with the development activity at issue. Reductions in those areas will necessarily lead to a reduced volume of activity in Software Configuration Management and Software Quality Assurance even though very comprehensive requirements of those KPAs remain part of the Project Portfolio Standard Software Process.
No matter how well conceived the grouping of projects into portfolio pipelines may be, there will always be the need for handling exceptions. A benefit of the Project Conduit approach is that these are real exceptions to a rule rather than an interpretation of the SW-CMM, which as a rule makes almost every project an exception. Exceptions are, simply put, variations from the project portfolio standard software process. The standard process itself should describe the method of documenting exceptions that may involve further attachments to the baseline portfolio documentation. Exceptions that involve eliminating certain process activity in an already scaled back environment should be carefully weighed against the attribute criteria used to group the portfolio projects but may be appropriate with the proper authorization and documentation.
Some projects, perhaps those in the most visible enterprise project portfolio, may be of sufficient scope and complexity as to require a unique project standard software process which incorporates virtually the entire OSSP and be significantly different for some projects in this portfolio. Implementation of such projects may make them appear to be project portfolio pipelines with a single component even though the project is identified as part of a multiple project portfolio. In most cases, this type of project portfolio will always have significant management attention and oversight. The attribute used to group these projects has more to do with their collective importance to the enterprise than those attributes used for defining other portfolios. The attribute in this case may even be that the project standard software process for each project is equivalent to the OSSP.
The use of this framework for CMM interpretation, in some ways, treats portfolio pipelines as if they were a single project and by extension may support the application of some project management process activity in the same way. It might be said that this approach is what some refer to as program management. The PMBOK® Guide description of program management (PMBOK® Guide 2000, 10) does have some similarity to portfolio management as used here but there are significant differences. The grouping of projects under a “program” most often includes projects that are not only software development and that are not projects but operational activities more related to a product life cycle. This conflicts with a key PMBOK® Guide definition that projects have “…a definite beginning and definite end” (PMBOK® Guide 2000, 4). Importantly, project portfolio management for software development projects as a focus for the SW-CMM implementation does not preclude program management activity where the software development is a part of the effort.
At the lower end of the project scale, implementation of the pipeline/Conduit model may present an opportunity for further grouping of activities that are denominated as unique projects but are of such small scale as to suggest they be redefined as activities within a more broadly defined project. Reducing the number of projects can improve management focus on the universe of organizational projects in a well thought out portfolio structure.
It is not the intent of this paper to discuss detailed implementation of the Project Conduit in a specific context. That is left to future efforts. The Project Conduit can form the basis of an organization's approach to management by projects, enhance the focus of senior management attention on the universe of organizational projects and, specifically, provide a framework for tailoring the Capability Maturity Model for Software to an organization's diverse multiple project environment and needs.If some consider the Conduit terminology awkward, I would refer readers to a quote that can be easily extended to this Conduit discussion; “The CMM is about doing things, not having things” (Paulk 1999, 8). Call it what you will, but if the concept leads to increased focus on a well-tailored SW-CMM implementation in a multiple project environment, the most important goal of this paper will have been realized.