Sunday, 08 July 2012 00:00

Stop All IT Projects!

Rate this item
(0 votes)

PDP11 ProgrammingAgain, I was chided for saying there are no Information Technology projects. This time, the excuse was that the company built software. I countered my antagonist by asking if the same group that built their software also maintained the account system, workstations, email, and network. "No, that is a separate group." He was missing that his company's production group was not IT. Information Technology is the support group... and yes, they should not be doing anything that fails to directly affect getting product out the door or reducing costs. Every project's goal must be to deliver to the operational needs of the company—selling product—not to the whims and desires of the IT group. If a project fails to address the needs of the customer (directly or indirectly), then it should never see a penny of funding. This seems such an elementary concept, but it is routinely violated by techno-bigots trying to implement the latest toy or tool.

The Almighty Customer


Companies make money by producing a product or service. Duh. Whether the organization is a multinational corporation or a small non-profit, improving how they function requires initiatives. These projects may work directly on a production line's capabilities, implementing new state-of-the-art materials, indirectly affecting the product by enhancing the infrastructure to reduce internal costs or increase capabilities, or any number of other topics—as long as they benefit the business. Regardless, a business case must be present that improves the top line or bottom line. Adding IT resources to a project does not make it an IT project.

Imagine to upgrade software project (service patches, database optimization, break/fix are not projects). If the business is not fully engaged with the change, trouble is on the horizon. For example, the IT group has a strong business case to upgrade from Office 2003 (losing support) to Office 2010 or Office 365, but the business has to assess the impact to their productivity. Initially, it will plummet. Over time it will recover and may actually get better (I have yet to see any productivity increase from this specific upgrade). The business has little desire for the pain. Hence, an information technology group supplies the resources, the guidance on what needs to be done, and the business owns the project of implementing it based on their perceived value. This job is selling IT's roadmap. If the business does not upgrade and they are caught not having support it is their problem, not IT's.

Connecting to the Business

Want to read more?

Strategy, alignment, communication of goals is not easy. Our Vision To Value white paper talks about focusing your team on the key strategic corporate goals and ensuring everyone in your organization knows the direction.

To help, CIOs need to get their group closer to the business. There are a number of techniques for them to do this. It requires confident and mature teams—not in the individual-contributors, but in IT leadership—from the CIO down to the first level management. The CIO needs to look at him or herself as a facilitator. It needs to be someone thinking less about his or her fiefdom and more about providing resources to the business. The resources are in three areas:

  1. People capable of turning business initiatives into reality. The classical approach of housing IT's delivery resources away from the business will save on moving costs and make it easier for functional managers, but it will destroy the teams ability to understand what the customer needs (not what they want, but what they need). Embed IT resources in project teams and collocate them with the business team. This improves project delivery and customer relations by merging the two teams into one.
    Implementing a distributed team does, however, require strong IT leadership. Directing and coordinating a dispersed group of technical people and ensuring they get the proper care and feeding to grow and flourish is hard work. The benefit is that resources resident with the business have a thorough understanding of the business's issues and propose better solutions.
  2. Utilities that allow the business to its job. The operative word is "utilities." Servers, telephony, networks, and COTS applications as we all know are about as unique to our companies as electricity. The goal should be to find companies that provide these utilities and hire them.
  3. Visionaries creating a cost-effective technology roadmap. Provide the architects and governance to enable the business to adapt rapidly to the future. In a highly distributed organization, where your teams report to business managers rather than in to an IT group, aligning them to a common roadmap is difficult. The architects must be more than technical wizards; they need the ability to sell their ideas to the IT executives, the business executives, and a distributed implementation team.

Distributing Your Team

Stop all IT projects and make them business projects. Their existence simply perpetuates the old myths of business silos. Technology is ubiquitous in the business and so should the IT group to support it. IT is no longer a mysterious and arcane subject practiced in computer rooms. It can be boiled down to simple tools for manipulating data for the end user to get the answer they need. Distributing the technical resources to help the business do its job is the next logical step.

More in this category:
Next Post Previous post
Read 7427 times

Leave a comment

Related items

  • The Catch-22 of Organizational Change Management

    "Kotter, ADKAR, or CAP which methodology should we be using to build our approach to improving project adoption?" I hear this question repeatedly from people trying to implement an organizational change management (OCM) program. The problem is that is the wrong question. Take a perfunctory peek at any of the models and you will see that in the quest for an answer people have mistakenly jumped over the first few steps. It is a Catch-22; unless you already have an OCM process in place, you will most likely fail at implementing it. Putting one in place, however, is a change—one of the most difficult cultural transformations that your company will undertake. As a result, people jump to the solution stage, which is well down the change management process path (which, ironically they did not know since there was no procedure in place).

  • Project Inception - Designing Organizations For Success

    Buy it now!

    A failing project’s fate is destined long before assigning a project manager. Its doom is sealed from the time the customer envisions the idea. Traditionally, project inception is defined as when the customer comes to a solution provider (internal or external to their organization) asking for a product or service. In actuality inception is much earlier. It starts when someone says, “Wouldn’t be neat if I could...” From that point forward the customer’s exceptions are set, changed, and reset as the process of discovery refines the concept. The customer’s ideas change from what they want to what they need, while continually constrained and formed by the realities of an ever-changing business environment. Although people cite unrealistic expectations as major problem during inception, the constant change in expectations causes the real issue—misalignment. For project managers to make a significant difference in a project’s success, they must use a new paradig.

  • Strategic Alignment: The Key To Project Success

    Buy it now!

    Project success rates for many companies and government organizations are dismally low, yet executives never seem to look at the big picture. They continue to make adjustments in the way projects are run by addressing isolated problems. However, projects are part of a much larger system and should be addressed in that context. To do that, companies must define how their strategic plan will use people, projects, and technology to achieve their goals. This paper discusses one approach to make this happen.

  • Transforming Project Managers Into Project Leaders

    Buy it now!

    Project management has been accepted in many businesses as a discipline critical for continued growth. To improve project performance, companies have levied rules on how projects should be run, defined common reporting requirements for all projects, and pooled and shared their project management resources. Even with these functions, projects still struggle to meet the needs of the customer. In order to improve project outcomes, the way in which they are managed must change. Project managers must become leaders, paying more attention to soft skills, managing their stakeholders, and identifying solutions to organizational issues that are limiting project success. The following paper discusses techniques developed by the author to address these needs and improve project success rates.

  • Vision To Value: Creating Successful Projects Using Leadership

    Buy it now!

    Value: Rather than scope, schedule, and budget, value is the lynch-pin of project success. Although the former three constraints are key factors in project success, there is no guarantee that meeting these constraints will result in a positive outcome. Instead constantly tracking the value of the project and making adjustments to the triple constraints to attain sufficient value is critical. Arguably this is the project managers most critical deliverable in the project. It requires significant insight into the project’s customer and a thorough understanding of their needs versus their wants. Project managers have to be leaders (leading subordinates, leaders, and customers), be able to assign priorities based on a critical, objective view.

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
Flag of the United States Buy it in Canada Flag of the United Kingdom
Flag of Ireland Flag of Germany Flag of France
Flag of Italy Flag of the PRC
Flag of Japan
Book sellers worldwide.