Tactical Control

Until this point, the majority of the discussion has focused on how BTM plays a crucial role in helping senior IT leaders govern the strategic direction of their enterprises , answering the question, "Are we doing the right things?" The other half of governance is tactical control: "Are we doing the right things right?" Once strategic direction has been established and communicated, management needs to ensure that it is implemented in a way that produces the intended results. This quandary is reflected in the fact that nearly a third of all IT projects fail or are abandoned before completion. That adds up to a whole lot of waste.

Clearly, there are a multitude of reasons why projects fail. So many so that I wouldn't be able to address how to resolve them all and still do justice to the topic at hand. That said, this section doesn't conduct a "Project Management 101" lesson; nor is it a "Program Management for Dummies" primer. There are a number of resources available in the form of associations, institutes, and published works that offer valuable assistance for the various aspects of the project and program management disciplines. This section does, however, examine the intersection between those disciplines and BTM.

Quality is "Job #1"

For years companies have worked hard to adopt and apply quality management techniques whose goal is to ensure that value-creating activities are conducted in the most efficient and cost-effective manner possible. This formalized practice of modern quality management dates back to the early 1950s and W. Edwards Deming, Joseph M. Juran, and Armand V. Feigenbaum, whose work, in addition to contributions made by the Japanese (Dr. Kaoru Ishikawa, Dr. Genichi Taguchi, and Shigeo Shingo), resulted in the Total Quality Management (TQM) or Total Quality Control (TQC) methodology. From there, a host of other quality methods have evolved across industries and functions, starting in 1966 with Quality Function Deployment (QFD) in the Japanese automobile industry and culminating more recently in 1988 with Motorola's Six Sigma methodology. (Although, that timeline could be extended out to 1994 with the introduction of QS 9000 by the then big three automakers, Ford, GM, and Daimler-Chrysler.) So if you make use of Pareto and fishbone diagrams today, you can kindly thank Joseph M. Juran and Dr. Kaoru Ishikawa.

The underlying point here is not to advise that a company should run out and embrace a particular quality management methodology ”the point is that companies have traditionally invested considerable time, resources, and money into figuring out how they can ensure that they are doing the right things right. Likewise, there should be mechanisms in place that help them institutionalize quality throughout their processes. Typically, companies formalize and/or enforce best practice quality methods by creating standards; however, the difficulty often lies in embedding these standards in respective processes. This is especially true for IT projects.

Much like the manufacturing product development process, IT projects are complex, with a myriad of inputs and outputs involved from the conceive and design stages on through the build, test, and deploy stages. As a consequence, there are a number of opportunities for costly errors or inconsistencies to arise during the project life cycle. In response, project managers at various levels rely on quality management techniques and standards to get the job done right ”meaning on time, on budget, and according to business requirements. These may be overarching project management standards such as those endorsed by the Project Management Institute (PMI) or Six Sigma standards at the business process level; or software engineering standards such as the Capability Maturity Model (CMM); or still others that are proprietary and developed in-house. But how closely such standards are followed depends on the ability of the organization to effectively inject these standards into the daily workings of these projects. The far-flung realm of IT, in combination with the scale and rapidity of the changes that IT is required to enact, make this a formidable task for even the most efficient companies. At any given time in large organizations there are literally hundreds of projects in various stages of deployment, in which there are hundreds of individual resources assigned to thousands of tasks that must comply with prescribed standards. How can even the most proficient project manager know or guarantee that these standards are being adhered to? How can the resources assigned to these projects be notified of these standards beyond traditional managerial oversight?

Once again, the principles and activities of BTM play an integral role ”this time in facilitating the institutionalization of standards. First, standards ”whether they are component design standards (e.g., Component Object Model [COM]), or engineering methodology standards (e.g., MBase), or vendor-specific standards (e.g., SAP solution map), or another variety ”are captured and codified in the business, process, and technology models produced during the activities of BTM (see Fig. 8.4).

Figure 8.4. Standards (such as EJB) that are captured in models are can be rolled up into the portfolio and provide the basis for analysis and decision-making (such as determining what types of projects currently utilize EJB)

Incorporating standards in enterprise models is analogous to encapsulating the detailed information necessary to satisfy high levels of quality compliance in the design specs for multi-phased production of heavy machinery or automobiles. For example, if you are rolling out a large-scale enterprise software package to multiple business units, you'd likely want to make sure that the rollout is standard in each and every instance to reduce risk, contain costs, maintain scope and timetables, and consistently map functional requirements to technology capabilities. In such a scenario, models would serve as the design specs for the IT initiative, enabling project teams to maintain consistent and repeatable levels of quality throughout each rollout. In the automobile manufacturing world, design specs can indicate, for instance, what parts should be used to guarantee that they are QS 9000 standard compliant; in the IT world, models can indicate what systems should be used to conform to data-level security standards. If you fail to build a vehicle with QS 9000 compliant materials, then potentially you've failed to build a car that is safe or meets consumer needs; if you fail to implement systems that conform to given security standards, then potentially you've failed to deliver a system that can get the required data into end- user hands. Design specs ”and their BTM-equivalent models ”keep designers and implementers in sync with quality standards.

Once standards are defined in the models, they are communicated up-front to the various project team members in the form of element attributes, properties, requirements, process maps, application or system pictographs, and such. Despite the normal management practice of regular meetings or the frequent release of internally documented guidelines, individual working groups often fail to follow universal standards. Project plans, procedural memos or manuals, and meetings help to communicate information about standards, but the ability to reinforce this type of knowledge is better provided by the models themselves . Traditional communication methods tend to fall short as they are more static than models and therefore have a temporal effect. The unique visualization afforded by models, however, substantially increases each project participant's awareness of (and ultimate adherence to) applicable standards at the time it counts most in the process ”during design and implementation. By ingraining standards in the models, project participants are exposed to this vital information on a day-to-day basis, resulting in contextual use at the activity level. Simply put, models make information public knowledge, not tribal knowledge.

Finally, by following BTM's principle of reusability, project managers can make certain that even far-flung project teams remain on the same page. They do this by creating and providing access to a repository of models that should be used as governing templates for upcoming projects. In this way, standards are globally propagated across functional and physical geographies, promoting widespread adoption and use. This of course, can be of particular benefit when certain tasks are delegated to external service providers who may be located off-site from the project or whose level of active involvement is irregular. Whether the project participant is internal or external, the use of templates helps project managers increase standards compliance, and by proxy, the derivative return that organizations receive on investment in such methods.

A Dollar Saved Is

According to best practice approaches, quality management is only one of several sub-disciplines belonging to the overall project management discipline. Likewise, cost management is one of several sub-disciplines belonging to the management of the project procurement process. Procurement management essentially focuses on controlling the acquisition of the products and services that are required to fulfill the objectives of the project. Cost management, in this regard, focuses on controlling costs so that the project is completed within approved budget parameters. Models play an integral role in the institutionalization of standards, so it is easy to understand how they facilitate quality and cost management by:

- Reducing maverick spending to safeguard against improper procurement

- Eliminating redundancies and waste to reduce or contain costs

Reduce Maverick Spending

The rebuke that IT decision- makers sometimes receive from the business side regarding inappropriate spending often stems from incidents involving maverick purchases. These purchases are maverick in the sense that they involve non-approved vendors or service providers, don't involve competitive solicitations, don't follow stringent vendor-selection criteria, don't incorporate standard contract terms or clauses, and so on. Maverick spending is detrimental in more than a few ways. Some of the most notable include dissolution of corporate purchasing leverage, use of unqualified products and services that quickly wind up consigned to the scrap heap, and unfavorable contract expenses and conditions.

It's not that corporations hold a cavalier attitude toward purchasing or shrug off the responsibility of trying to prevent such instances of squander. Many corporations devote entire departments to formalizing purchasing procedures for the express purpose of combating these errant expenditures. The problem is that they still struggle to universally communicate and enforce these standards. Guidelines and procedures prescribed in a five-inch thick binder have a tendency to get lost in the organizational translation process.

The last section explained how models codify and institutionalize quality and implementation standards. The same is true for corporate purchasing standards. Through the use of models, project participants have immediate visibility and access to these standards at the most critical moment ”during vendor evaluation and selection.

To illustrate what I mean, here's a short example: The corporate IT department for a large, multinational conglomerate determines that to save money on integration costs, all CRM projects will be required to install a package from Vendor A. To enforce this standard, the architects create templates that earmark elements pertaining to Vendor A's offering (e.g., functional requirements, specifications, compatible operating systems and hardware, etc.) as the approved vendor. These templates then become a part of the PMO's repository for reuse on similar initiatives. Subsequent use of these templates ensures that when a new CRM project is begun in any of the company's business units, architects don't deviate from the standards and Vendor A remains the selected provider. In this way, the models act as a powerful mechanism for enforcing corporate purchasing standards and preserving spending integrity.

Eliminate Redundancies and Waste

From a cost-management perspective, it is the program manager's responsibility to determine appropriate resource (physical, human) levels, develop cost estimations, allocate budget amounts to tasks, and control changes to cost structures. ^[4] Bear in mind the scope of the task at hand ”hundreds of projects running in parallel with hundreds of physical and human resources involved. The first step in managing this process is to identify and eliminate redundancies between projects. The decentralization of IT, mergers and acquisitions activity, and globalization are just a few of the major factors contributing to the vast amount of redundancy that already exist in many enterprises. New initiatives shouldn't add to the current level of waste; at the same time they should be used as opportunities for right-sizing IT allocation.

Models are valuable tools here because they help to clearly identify elements that are currently shared or have the potential to be shared between projects at the business, process, data, application, system, component, and functional requirement levels. It's shocking, but more than a few organizations don't really know what resources they already have in-house and how they are being utilized. I'm not talking about keyboards and mice here ”I'm talking about big-ticket items like rack-optimized servers or enterprise software packages. Models contain dynamic linkages and references between elements that enable architects and managers to gain this critical insight. And, the depth of insight provided by the models goes a long way toward promoting the reuse of functionalities, processes, and technologies that would otherwise go undiscovered. Through models, not only can project managers highlight and excise waste, they can also uncover opportunities to optimize cost-benefit ratios.