Do projects matter for IT?

This is a guest post by Aren Cambre. Aren is a manager of web technologies at an educational institution. The way he explains it is, “If the web site looks like crap, they’re yelling at public affairs. If it’s broken, they’re yelling at me.” He has a M.S. Computer Science and is plodding towards a doctorate. His personal blog of random mis-mash is at http://arencambre.com.

Information technology (IT) focus is shifting from classical projects to agile services.

Here’s why.

Reason 1: Much of IT defies project definition

A classical project has a predetermined start, end, and result. When done, the result goes into “maintenance mode”, and you jump to the next project.

But what if something never has a “maintenance mode”?

For example, the web is never done. A university’s web site must be exciting and work quite well; the key audiences are technologically progressive prospective and current students. What university wants technophobic students? Relevant university sites must keep up with rapidly evolving consumer technologies.

A university’s web site is a good example of an agile service: an adaptive mix of agile applications and expertise. These are where a lot of IT’s attention is going.

Agile services don’t end. They are not classical projects.

Reason 2: Small projects don’t matter much

Isn’t a service just a lot of mini-projects? And isn’t the last trend to make projects smaller?

Neither matters much. Small projects are really large tasks or iterations in an agile project.

By themselves, small projects don’t tell the value of IT. Agile services do.

Reason 3: Virtualization and clouding

The largest classical IT projects are implementations. Virtualization and especially clouding make it easier to create new things, sometimes almost erasing implementation projects.

Taking away implementation focus shifts attention to maximizing value of existing investments. Again, emphasizing agile services at the cost of classical projects.

Reason 4: Agile is where it’s at

Classical projects use waterfall, a prescriptive method from the manufacturing and construction industries. It’s from a time when the pace was steady, change was resisted, and top down was how it happened.

Relevant IT is the opposite: fast-paced, adaptive, and responsive. That’s why agile project management is natural for IT: it encourages adaption, continual reassessment, early problem discovery, and faster completion.

I’m not the only one seeing this. A proxy is Atlassian JIRA versus Microsoft Project Server. JIRA is for agile, whereas Project Server is for waterfall. Look at their Google search trends (source):

But this isn’t just about improving how projects are done. Agile does something that waterfall can’t: manage services.

Paraphrasing Men In Black II, “Waterfall projects: old and busted. Agile services: new hotness.”

Do classical projects belong in IT?

To be clear, classical projects still have a place in relevant IT. Really complex projects aren’t entirely going away, and some may need waterfall. Same goes for projects with well-understood paths and vanilla outcomes.

However, “well-understood” and “vanilla” are starting to be outsourced, such as email, web systems, ERP systems, and more. If not outsourced, they may be heartbeat functions, increasingly undifferentiated from plant operations. Or their business value is not intrinsic; the value is in what others—users, innovators, developers—can wring from them.

Agile services are the future of IT. It’s how we work, it’s how we provide business value, and it’s how we communicate what we do.

Image Credit: Project Management Lifecycle By Ivan Walsh on flickr