Remember at the turn of the century we were all convinced that the age of information was over and now we were entering the Era of Knowledge. It was supposedly the era where companies would start putting to use all the data they’d been collecting over the last decade. It was where technology could really start being leveraged, and all this data analyzed, to drastically improve business operations. What happened? Did we ever really get there? I’m not so sure we did.

Don’t get me wrong, effective use of technology in the enterprise has improved dramatically over the last decade. Nonetheless, it seems that most companies never really got out of the information era. They are stuck in a cycle of spending their budgets on maintaining and upgrading existing systems. By the time they get a system to point where it’s performing the necessary business functions, they realize it’s technically outdated and are either forced to start over with the latest technology or risk being left behind. There are a few key areas that companies need to analyze to start to solve this problem.

Companies need to learn to avoid “technology creep” which can happen over a period of years. The term scope creep is widely used to label the situation where a project’s requirements grow beyond the initial capacity of the project. At a coarser level, technology creep is the situation where the infiltration of different technologies into an enterprise grows past the enterprise’s ability to effectively support, maintain and integrate the technology. This tends to destabilize the enterprise, which hinders an organization’s ability to move ahead.

One of the primary factors that lead to technology creep is the lack of communication in an enterprise. Larger companies usually have an architecture group and individual business units to build the business applications. What tends to happen is that the business units are stuck on the fringe struggling to keep up with the needs of their business. Needless to say, the corporate strategy set forth by the enterprise is usually just noise and sometimes considered a hindrance by these business focused teams. Most of the time this is due to the business units being left out of enterprise decision making process when it comes to the technical strategy. An enterprise policy that facilitates communication across all technical groups and that takes into account existing technologies in the business, and individual business unit needs is paramount to stabilizing the enterprise.

Another factor leading to technology creep is incomplete or inconsistent standards set forth by the architects. All too often, when a development team is out designing a new project they may be mandated to use a specific technology, infrastructure or API, but the details are left to them to decide. Project templates for all levels of the application development including the GUI, Business Services, Persistence, Logging, Error Handling and other core application services can go a long way to standardize technology across the enterprise.

Enterprise services to maintain source control, build processes, development and test beds can go a long way to standardize the way applications are developed. Further inter-business unit design, and code reviews can go a long way to standardizing technology.Another important issue that is hindering the ability of companies to move forward is the lack of a comprehensive integration strategy. Unfortunately, this is an item that is all too often analyzed at the application level instead of the enterprise. Development teams are left thinking… “How am I going to make my system talk to system X to get the data I need”. They don’t usually think about an enterprise data integration strategy. A strategy that maps all the data in the systems across the enterprise as well as the flow of that data is crucial to improving the performance of the enterprise.

Summing it up, the efficiency of technology development has a lot to be improved. There is plenty of data being stored and processed in most enterprises, but the lack of communication, implementation standards, and integration strategy is hindering most organizations ability to get ahead and realize their full potential.

One of the biggest barriers to effective performance measure implementation is the development of “stovepipes” inside organizations of people and information. Stovepipes are more than just information technology systems built and bundled independently over the years. These systems stovepipes are effective obstacles to comprehensive performance measures as they make it difficult to develop and track meaningful performance metrics across the organization. CIOs often find themselves with an “apples and oranges” situation.

Organizational stovepipes or silos are also massive impediments to effective measurement. These silos can exist even when the technology is similar or exactly the same across the organization. They are damaging to performance measurement implementation because the people themselves are creating the roadblocks – not the technology. In forwarding a parochial set of metrics and espousing narrow thinking that only considers a single aspect of the organization, managers will make it difficult if not impossible to create an effective performance management system organization-wide.

Why do some managers create barriers? To be fair, most stovepipes usually were created well before the current management to over the reins. Plus, compensation and other organizational performance measures have reinforced the stovepipe mentality. Think of the organizational chart. Managers are very concerned about the part of the organization that is directly underneath them – it even looks like a stovepipe.

So how do we bring people together and turn these stovepipes into connectors. Aside from a complete organizational overall, which is impractical and beyond their control, CIOs can effect real change in organizations.

One of the most effective tools for this process is the creation of a Program Office for implementation of performance measure implementation and tracking. This office breaks into the stovepipes by creating centralized ownership of the PM program and coordinating maximum participation by various organizational components. While this office may have other responsibilities, there was dedicated staff and resources to the PM program. This office was the organizational PM nexus for:
- Communication
- Data Collection
- Presentation
- Business Unit Support
- Review & Feedback

Another effective tool is creating a common PM training program. By bringing together professionals from across the organization and have them share a common experience in learning about the new PMs, the barriers of their respective organizational silos.

Of course, hopefully, the CIO and his team did a great job of collecting the input of the various business units, functional leaders, and senior executives when developing the PMs. Metrics that can be meaningful to everyone are a great way to connect an organization and encourage positive performance.

There’s been plenty of discussion in both literature and general media about “most software projects failing.” There are plenty of reasons for failed projects: from inadequate requirements gathering to poor project management to plain incompetence. Some of the problem starts at the C-Suite where projects are actually identified and started — for asking to automate (presumably with software) something that maybe has no business being automated.

My simple advice to most CEOs and CIOs about project management starts with a question: can you methodically and manually repeat the thing you are trying to automate? If the answer to that question is “no” then no PMO, no project management technique, not even the smartest most talented people in the world can help automate something that can’t at least be repeated consistenly manually.

This advice of asking a simple question about repeatability might sound so obvious as to not even bother asking it but it becomes perilous not to do so. At the heart of most failed software automation attempts is a failure to understand the workflow and gather the right requirements. That’s pretty easy to figure out. What’s not so easy to figure out is: why is the workflow so hard to gather requirements for? It’s probably because the workflow, while it seems consistent at the high level, isn’t repeatable enough consistently to describe in software. Perhaps parts of it are, but maybe the entire workflow isn’t.

So, as a senior executive that may not be leading the project, but may be greenlighting it, what you need to do before making a decision is have your project managers describe that they can clearly repeat (manually and consistently) what they are trying to automate. If not, get the process engineering guys in there to work on the process before the geeks get in there to work on the technology.

Financial Indices

All executives place a heavy emphasis on IT programs and projects remaining on target in regard to their budget. As a result, we found most of the use of and impetus for the development, implementation, and utilization of Performance Measures revolves around financial factors.

Strategic Factors

All interviewees discussed beyond financial goals and factors (every organization had reduced cost as an important goal) there were strategic goals that were endemic to their enterprise and its mission. These goals are formulated through elaborate strategic planning processes.

Performance measures, especially IT PM’s, need to be aligned to these goals and objectives. “Performance Measurement is not an end, but rather the means to achieving better management results,” according to the Government Accountability Office.

External Benchmarks and Standards

Most organizations view that the external measures, like scorecards, benchmarks, and standards, are good baselines to begin an analysis or measurement process; however, independent PM’s are needed to capture all the needed information.

Many interviewees commented that their adopted metrics were NOT inconsistent with the metrics established by these external studies and standards organizations.

Internal Metric Development

90% of all interviewees believed that “internal metric generation” was the preferred method of developing Performance Measures.

In our study, internal metric generation stood for the development of metrics by organizational constituents - not borrowing metrics from external sources. This was primarily done from “bottom-up” recommendations from operational or staff managers or technical experts. When these were developed at the executive level, most of the time they were conceived with staff discussion and involvement.

IT Committees, councils, and roundtables were the primary vehicle for collecting these metrics.

NEXT: I will discuss Performance Measure Implementation.

CIOs today find themselves, like other executives, struggling with the notion of accountability. CEOs, CFOs, and Boards in the private sector and Agency leaders, Congress, and legislatures are all demanding technology executives measure the performance of their areas and show real improvements and/or successes.

My firm, Mass Management Consultants, Inc., was asked by a public sector client to examine the issues with setting performance measures for IT departments. We conducted a systematic analysis of the academic literature and business press to identify best practices and preferred methodologies. Additionally, we identified a dozen high-performance IT departments and conducted in-depth studies of these organizations including personal interviews. These were a cross section of Fortune 500 companies, large private corporations, universities, and government agencies that have achieved significant recognition for their IT efforts.

We discovered some really intriguing success stories and were able to develop some distinct insights into the process of creating and implementing effective performance measurements for IT areas.

IT Governance

One of the most important issues that we found needed to be addressed before the implementation of IT performance measures was the adoption of appropriate IT Governance – “Who makes the decisions? Where do you spend the money?” Every interviewee pointed to the importance of governance on the successful adoption of IT performance measures.

The following chart describes our finding that the effort needed to implement of IT performance measures is inversely proportional to the level of governance concentration. Organization III struggled to implement measures because IT served merely as a service provider and policy was in the hands of a dozen autonomous units.

We found that:

•    Generally, the more decentralized the organization, the more complex the development and implementation effort must be for maximum utilization.
•    Committees, boards, and roundtables play a key role in decentralized organization.
•    A well defined “command-and-control” system can replace other more collaborative structures.
•    Outsourcing of IT services can create a serious challenge for PM development and implementation.

The National Association of State CIOs (NASCIO) has an interesting research paper which explores some of these issues.

NEXT: I will discuss the other critical factors that go into creating effective IT performance measures, including financial indices, strategic goals, external ratings and benchmarks, and technical criteria.

This is a business and technology strategy advisory blog run by Shahid N. Shah and Randall Mass. Our objective is to give actional business and technology advice to senior executives such as CIOs, CTOs, CEOs, and CFOs to help them raise their companies “above the rest”. Mediocrity creeps into business and technology groups when strategy is not aligned with business goals and we hope to help solve that problem in a small way through this blog. If you have some thorny business or technology problems that you’d like us to write about, contact us by leaving a comment here or e-mailing us directly. Don’t worry, it won’t cost you anything.