Sunday, 15 May 2011 00:00

The Progressive CIO's Model for Project Success

Rate this item
(0 votes)

Information Technology organizations continually struggle to build systems that meet their customer's needs. They work tirelessly developing solutions that are delivered late, difficult to use, or deficient in key features and functions. This is nothing specific to the last couple decades; it stretches back to the first systems developed. Fredrick Brookes eloquently underscores this in his recount of the 1960's software engineering project to develop the IBM 360 in his book The Mythical Man-Month (1975) and is required reading for all IT executives. For the Chief Information Officer to solve this problem takes a new approach, one, nearly opposite from today's direction.

A Different Approach

As with many solutions, the answer is not found in experimentation but in observation. End-user computing, the oft considered anathema of IT professionals, provides the hint. This is the group of business geeks who construct what IT appears incapable of building. Using tools like the Excel and Access they create applications that automate and streamline their business's flow. Unfortunately, these systems are frequently deficient in the robustness required by the enterprise. End users lack the tools, training, and experience to detect those flaws until they have need integration with other applications, multiuser access, or restoration of lost data. The common answer—moving the application to IT and rewriting it to handle the enterprise requirements—is accompanied with huge capital expenditure, frustration from languishing in the development queue, and significant ongoing maintenance expense. This scenario is repeated time and again in organizations around the world, achieving identical results—a dissatisfied customer. This answer needs to be rethought. If the user is better at creating useful applications and IT builds better infrastructure, then create an organization to mimic that model.

Like The Business

Want to read more?

Keeping customers, vendors, project members, and other stakeholders together on projects needing heavy IT involvement can be a challenge. Our Project Inception - Designing Organizations For Success white paper talks about redesigning your organization to achieve the best project results.

The mantra of the past is to run IT like "a" business. However, the unintended consequence distances IT even further from the customer. IT should not be run like "a" business, but, rather like "the" business, aligning to their goals, understanding their pain, and rapidly responding to their needs. To achieve this, IT's business analysts, developers, quality assurance, and project managers must be placed in the business unit.

Architecture and infrastructure should remain collocated and used as shared resources. This ensures IT's foundation is solid and it can respond to the business. This core IT group needs to focus on providing a robust backend that will accommodate the customer's strategic plans. They provide the adhesive glue and support for the business's initiatives.

In a recent chat with Jim Highsmith at It's About Coffee, he explained how he approaches the problem using the agile principles. Covered it in a recent article, he points to the solution of how quality and value relate to the traditional triple constraints. I am calling the combination of the triple constraints, value, and quality the business constraints. The project constraints are just a subset of these overall business constraints (see inset). Applied to the model above, the business is responsible for the IT supplied project teams. Project success is measured by balancing value, quality, and the triple constraints.

The concept of the IT project has vanished, there are just projects using IT resources. The business owns ensuring the value, the architect owns the quality (robustness, reliability, technical debt, extensibility, etc.), and the project manager must tune the triple constraints to meet the quality and value needs. This creates a new paradigm for managing project where the focus is not a tactical scope-schedule-budget, but includes the strategic components of value and extensibility/quality.

Since most IT organizations service numerous business objectives, it needs to maintain the optimal architecture to achieve all the business's strategic goals. This is accomplished by providing the means to complete the project, including the technical resources and the architecture.

Project teams, resident with the business, have a much clearer picture of the needs; hence, they focus their efforts on tuning the triple constraints to provide value. Accountability resides with the business, where it should, all team members are responsible for designing and building an application addressing the problem, and IT provides the tools and resources to create those applications in an enterprise worthy manner.


The challenge is maintaining a common direction for the IT resources and ensuring an adequate pool of resources to match the company's strategic goals. This requires frequent training in the skills and tools that are required for proceeding down business's strategic roadmap, strong IT governance, and a unique combination of confidence and leadership to guide a distributed IT organization. This starts with a CIO who is indifferent to the number of floors his or her staff occupies or the latest shiny-ball technology. Modern CIOs need to foster superlative communications throughout their ranks, wherever they may be located.

By divesting the project teams to the business, the modern CIO helps inculcate business operations knowledge into the IT staff, resulting in IT becoming a well-respected and valuable organization within the company. Leveraging this added strength bolsters the position of the CIO to one that is critical in running the company—one deserving of a seat at the C-Suite table.

Read 10921 times

Related items

  • Process Mapping

    Process is at the core of any business. It makes work predictable, repeatable, and transferable. Without it we cannot scale our businesses. However, process can be a bane to making progress. Processes that work for a $10 million company have difficulties supporting a $30 million company. Trying to scale them to a $300 million company will not only fail but not address the issues that larger companies have that were never dreamt of in a smaller organization. Processes need to be discarded, revamped, and built—all of that without creating an overburdening bureaucracy.

    Anytime you need to go someplace, you first have to know where you are. Processes are never static and your company's current state is probably far from where you think it is. Hence, the first step is mapping out you company's current state followed by defining the future state. This is more than a logical map of the process; it must also include physical maps. Whether your process is solely to provide a service (say, website development) or physical (say, manufacturing) there are logistical issues that complicate the process flow. Without fully understanding those nuances, future state processes will not reach the desired efficiencies.

    For more information about process mapping fill out the form to the left and we will get in touch with you.

  • Success vs Culture

    The other day a Latvian student contacted me for my views the connection between culture and success criteria—an important and intriguing topic. After working in Taiwan, Singapore, Korea, Japan, Israel, United States, and Canada, I wear many scars of both blatant and subtle cultural violations. I also know that within a culture one person's success is often another person's failure. So, after dispelling concerns about clicking on some random email link, I completed her survey (please feel free to take it yourself). In the process, I struck up a friendship with the student, Kristine Briežkalne, who is studying at Riga International School of Economics and Business Administration . She has some interesting views and presented me with a Venn diagram showing four frames to a project (business, client, project management, and growth perspectives) and how they intersected. As the diagram is part of her Master's thesis, I will let you ponder the how to label the overlapping areas (an eye-opening exercise).

  • Kill The White Knight

    There is a reason we do not teach classes on fixing failing projects. Many a cynic feels that we simply do not want to teach our trade, however, our reason is far nobler—we should be teaching prevention rather trying to create white knights to save the day. It is the same philosophy as building a fence at the cliff's edge rather than an emergency room at its base. Our language is replete with idioms telling us to look past the symptom and address problems at their root cause. 'An ounce of prevention versus a pound of cure' or 'a stitch in time saves nine.' Please, feel free to supply your own in the comments. Unfortunately, most of our businesses loathe this philosophy, waiting to address an issue until it is irrefutably broken.

  • Comparing Organizational Change Management Models

    A few weeks ago, I set out to write a post on the comparison of various organizational change management (OCM) methodologies and realized that would be a disservice to my readers. It would simply drag you down the path of implementation while failing to focus you on building the foundation. The pressure was too much and I have relented to numerous requests on making that comparison. The caveat is that juxtaposing these models is not comparing different varieties of oranges or even apples and oranges; we are surely comparing the peel to the fruit they contain. Hence, comparing methodologies like Kotter's model (the peel), Prosci's ADKAR (the core), and General Electric's Change Acceleration Process (the whole fruit) need a different approach.

  • The Executive-Project Manager Gap

    It was such an innocuous question, "Working on an article; what is the biggest problem you see with project governance at orgs? Can you comment?" Can I comment? Really? That is like cheese to a mouse. Where could I start—bureaucracy, draconian process, poor executive sponsorship, disengaged leaders? Plenty of fodder, because they all lead to project failure. I fired off, "Creating an over bureaucratic morass stifling innovation & implementing process instead of cultivating leaders." Then the maelstrom started and it went directly to the gap between the executives and projects managers. Naomi Caietti, Robert Kelly and I had a great conversation. Most of the thread is below.

Leave a comment

More Info on Project Recovery

Tell me More!

Please send me more information
on fixing a failing project.

Rescue The Problem Project

Internationally acclaimed

Image of RPP

For a signed and personalized copy in the US visit the our eCommerce website.

Amazon logo
Buy it in the United States Buy it in Canada Buy it in the United Kingdom
Buy it in Ireland Buy it in Germany Buy it in France
Buy it in Italy Buy it in the PRC
Buy it in Japan
Book sellers worldwide.

Upcoming Events

Other's References