ecaminc.com

  • Increase font size
  • Default font size
  • Decrease font size
Home Blog: Back From Red General Blog Stop All IT Projects!
E-mail Print PDF
RSS

Stop All IT Projects!

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

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

Delicious Delicious
Add to Technorati Favorites

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.

Tags: , ,

Previous Blog Next Blog
 

Comments  

 
-1 # geoffB 2012-07-09 02:56
Nothing new in all that, and I'd say that Companies make money by satisfying a need (effectively, efficiently and in a client approprate manner) and not just by "producing a product or Service" (a very Prince2 focus - ironic given the flavour of the article perhaps?).

btw, agree with most everything said, and ITIL v3 certainly places the Client Need / Value in the spotlight now (sadly haven't seen it translated into IT Ops culture and Management though).
 
 
-1 # Bill Scott 2012-07-09 18:12
I agree that we need to move away from call any project with an "IT" component and "IT Project". If you assume mal-intent (the opposite of assuming good intent), labeling something an "IT Project" is a handy way for "the business" to absolve themselves of responsibility for failure. Is an ERM implementation project an "IT Project"? Hardly.
However, we've found that embedding PMs into the business lines often results in PMs doing "non-PM work" basically anything the Business Director needs done, e.g. firefighting for the Business Director without a clear project defined. The PM becomes the Business director's PM and God help you if you try to assign them something that is not on the Business Director's To Do list.
So...in the world of a PMO and a Business line, who gets to decide what the PM works on? The PMO (projects) or the Business ("things that need doing")?
 
 
0 # Terry Schmidt 2012-07-11 09:59
Great reframe and demonstrates the power of language. I'll put a slightly different spin on it because ALL projects should be business projects, rather their functional home is marketing, finance, or whatever.

Perhaps the reason IT projects stand out as a label is because there is often less up-front clarity on the link to business objectives. A very simple -- but not simplicstic -- solution is the concept of a strategic hypothesis, connecting deliverables to higher objectives.

That's the logic in my book STRATEGIC PROJECT MANAGEMENT MADE SIMPLE (WILEY, 2009) which was labeled by baselinemag.com as a "top ten must read book for IT managers". It provides the framework for intelligent dialogue between the IT pros and the intended user of IT products.
 

Currently comment rights have been restricted to registered users only. Please try registering and logging on.


Who's Listening To Us...

Fortune/CNN Money logo
 
Forefront's logo
 
Logo Oregonian/OregonLive
 
Enterprising CIO's logo
 
Slashdot's logo
 
The CEO Magazine's logo
 

Read and Hear More...


Visualize Your Future

Change how you do business.

Project Failure Insight:

The following blogs regularly have articles on project failure, recovery and good management practices.
Chris Curran
CIO Dashboard
Michiko Diby
Preventing Project Failure
John Estrella
Dr. John A. Estrella's Blog
Mike Krigsman
IT Project Failures on ZDNet
John F. Moore
Random Thoughts of a Boston-based CTO
Roger Sessions
Simple Architectures for Complex Enterprises

Looking to buy the internationally acclaimed Rescue the Problem Project?

Image of RPP

For a signed and personalized copy in the US visit the book's website.

Not in the US? Try one of these book stores worldwide

Amazon logo
Book or Kindle
Flag of the United States
United States

Flag of Canada
Canada

Flag of the United Kingdom Flag of Ireland
United Kingdom

Flag of Germany
Deutschland

Flag of France
France

Flag of Italy
Italia

Flag of the PRC
中國
Flag of Japan
日本の
Barnes and Noble Logo
Book or Nook
Sony Reader Store logo
Sony Reader
Worldwide: Many other
book sellers worldwide.

Recent and Upcoming Events

Suggested Books

Many of these books have reviews in the "Books to Read" section of this site.

The Toyota Way
by Jeffery Liker

Related Items