Sharing IT's tools

Dwight Horch was telling me about his project management tool. "What's happening is that it's being used for projects outside information systems and technology," he said. "They're using it in marketing, research and program direction."

Imagine that: Users swiping a tool from the IT people.

If that sounds weird to you, well, it just points up how far we really are from all that stuff we spout about the importance of aligning IT with the needs of the business. Align IT with the business? Heck we don't even want users to borrow our tools.

In case you're wondering, Horch is executive director for IT at Educational Testing Service (ETS) in Princeton, N.J. (Yes, they're the SAT people.) The tool he likes so much is Project Office from Pacific Edge Software Inc. in Bellevue, Wash. He likes it because it fosters collaboration, because users can do useful things with it after just a few hours of training and because the system kicks out actionable management information early in the project process.

But this column isn't about Project Office. It's about what happened after Horch brought it into ETS to get a handle on his hundreds of IT projects.

People in other departments - businesspeople, not IT people - started using it. They used it because they were involved in those IT projects. They found it useful. They liked it.

So they adopted it for their own projects.

Wait wait, you're thinking, we don't do that. We don't let users fool around with IT shop tools. We keep that stuff safely away from them, so they don't get into trouble we'll have to bail them out of.

We want them to handle that business of building bulldozers or selling shoes or making microwaves. They should stick to the automotive or grocery or insurance business, whatever it is our company does. And they should leave IT's tools alone.

But we've got it wrong. Good things happen - the best things, in fact - when users start borrowing our tools. That means they're working with us closely enough that they know our tools. And if they know our tools, they've started to understand what we do and begun forcing us to understand what they do.

We need that. In IT shops, it's so easy to slip into that technology cocoon: heads down, turning requirements into code, specs into systems.

No, it's not as bad as it used to be when users tossed requirements over the wall and, two years later, IT threw back a system. Today, we meet with users and develop use cases and give them a prototype or two before we deliver the product.

But too many of us are still focused completely on bits and wires, speeds and feeds - and never on understanding the business of cars or shoes or insurance that the rest of the company is doing.

And without that understanding, we'll never really get it right. We'll never create e-commerce applications that actually sell the goods, or implement supply-chain management that makes the assembly lines and warehouses perform better. We'll never build business systems that really do what the business needs.

Users getting their fingerprints all over IT's tools doesn't guarantee that we're making the connection, of course. But if they're getting in that close, it's likely we're on the right track.

Think of it as a new yardstick for how well we're doing our job of delivering IT for the business. When users are satisfied with the systems we deliver, that's good. When they participate in developing those systems, that's better.

Join the newsletter!

Error: Please check your email address.

More about Educational Testing ServiceIT PeoplePacific Edge

Show Comments

Market Place