The organizations we serve are changing… are you ready?

CIO Magazine recently published a Q&A with James P. Andrew, titled “The Secrets of IT Innovation.” In this, Mr. Andrew leads out saying, “The biggest problem in innovation today has to do with money. In other words, how do I generate return on my innovation spending?” Exactly!

In fact, surveys say that two out of three CEOs expect to drive fundamental change within their organizations in the next two years. Often times this includes organization change. Today’s organizational structure may even be misleading – if the business hopes to use new applications or products to change the way they do business in some significant way.

So what’s the approach to handle this? “Know what’s on the agenda of business leaders and what goals for the business they have.” Right again!

There’s just this major rub: how do you translate the advice into some practical actions?

The first step is to understand who you’re serving: the stakeholders. Your line of business executives are the first folks you might think of – they need to be satisfied with the app, as it is their business that is affected. But they’re not your only stakeholders.

You also have to consider the end users, the IT operations folks who run the app, or maybe even the architecture team that mandates a given approach. In addition, if you use vendors to build or run parts of your environment, then they too are a stakeholder group.

Focusing on stakeholders and developing a clear understanding of their goals is the very essence of outside-in thinking. It allows you to maintain focus throughout your product’s development, and it makes clear whom you must satisfy to achieve business success.

A good next step it to think about organizational context. Your work as a developer is affected by the structures, cultures, and initiatives of your line of business’ (or customers’) organizations. You need to understand these structures because your stakeholders will make decisions that reflect their organizational contexts, and they probably want to use your applications to effect further changes.

For example: is the application roll out to be highly distributed (each regional office runs it themselves), centralized (run from the top), or federated (run regionally but also managed from the top)?

The outside-in development advice is: know your stakeholders, know their needs. Easy to say, but the work beneath the words is significant. I’ve captured some solid practices in my book on this, and would welcome comments from folks who have other experiences to share.


(Image attribution: http://www.freefoto.com/imagelink/?ffid=04-28-36&s=s)