Commentary

Chris Murphy
Editor, InformationWeek  

When Pain Is Written Into The IT Project Plan

In a complex, multi-year business-technology transformation, everyone knows there will be problems. Yet most don't do what Rockwell Automation CIO Mike Jackson did: Put that reality in writing at the start of the project plan. Here's how and why Jackson and his fellow leaders did that.

In a complex, multi-year business-technology transformation, everyone knows there will be problems. Yet most don't do what Rockwell Automation CIO Mike Jackson did: Put that reality in writing at the start of the project plan. Here's how and why Jackson and his fellow leaders did that.Rockwell Automation has been on an impressive journey of global process transformation, and I've been fortunate to hear Jackson present about the effort, including at the recent Wisconsin IT Symposium. There are a lot of lessons from the company's effort, but a simple, powerful one is how the project leaders--a team drawn from business-unit and IT roles--made clear up front that real organizational change doesn't happen without a level of pain.

In the operating principles for the project, first on the list is this:


More Global CIO Insights

White Papers

More >>

Reports

More >>

Webcasts

More >>

Our business processes and practices will change significantly, and we will accept some disruption to achieve the ultimate benefits.

Jackson heard a few too many times from people that the transformation project sounded like a good idea, just as long as it didn't disrupt their businesses in any way. Rather than pretend this would be the first big project in the history of big projects that didn't come with problems, the leadership team took that idea head on.

There are a lot of risks in a major effort such as Rockwell Automation's. One of the sneaky ones is that a company doesn't change enough, that after all the sweat and cost the business is merely tweaked. A principle like Jackson and his colleagues laid down is at least one hedge against that risk.


Related Reading




Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

InformationWeek encourages readers to engage in spirited, healthy debate, including taking us to task. However, InformationWeek moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. InformationWeek further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
T-Shirt Giveaway T-Shirt Giveaway: Each week we're selecting one great comment from our readers. The author of the comment will receive an InformaitonWeek Community t-shirt. So get posting!
Subscribe to RSS

Resource Links