Sunday, 08 July 2012 00:00

Stop All IT Projects!

Rate this item
(0 votes)

Again, 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.

Read 8775 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.

  • Tales of an Expert Witness: Sex, Lies, and Video Tape (Part II)

    Trust relationships, certifications, and standards sound like such a safe harbor. These sound like such great words in a proposal or statement of work. How could you possibly go wrong building a trusted relationship with a customer by committing to follow a standard? In fact, this can burn you… in court.

    No one ever starts a project with the goal of ending up in court. In fact, litigation may never cross your mind; after all, you have built a trusted partner relationship. Taking a few cautionary steps, however, will make your life easier if you end up in that ill-fated litigious position. Your best chances for success come long before you enter the courtroom—even before the project starts.

  • 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.

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

Sitemap