Putting one foot in front of the other (part 2)

In a previous post, I suggested some of the fundamental, structural changes I think IT will have to undergo in the next 10-15 years. And to me, these changes are not optional: organizations will have to make them; the only question is who will risk the difficulties and step up to lead them (and reap the substantial rewards)?

With that done, I’ve come back to Earth a bit to kick off a series of more modest posts that look at some of the baby steps IT needs to take to evolve into a truly strategic capability.

To me, once an IT leader adopts the correct orientation of her department as a strategic asset primarily focused on delivering business value (rather than IT capabilities), she has a number of very tactical areas to address:

  1. Demand pipeline
  2. Structured requirements
  3. Developer-heavy staffing
  4. Agile methods/approaches
  5. Service catalog
  6. Portfolio management (including rationalization)

In this post, we’ll take a look at the second, structured requirements.

#2. Structured requirements

Last post, we focused on the demand pipeline, but really it can’t be fixed without fixing your approach to requirements gathering at the same time. After all, you prioritize the pipeline based in part on what each project will deliver, how much it will cost (in time, resources, and dollars), and how long it will take to complete, and you can’t know any of these things unless you’ve done some requirements gathering around each project.

In my experience, managing requirements is a critical area where most IT shops fall down in one of two ways: way too much of the wrong kind of structure or way too little of any kind of structure.

And often, a single organization spends many years alternating between these two poles every 18-24 months. We’ve all been there: fed up with the wild west approach to capturing requirements (on the back of a napkin, in a single phone call with a LOB stakeholder, etc.), IT develops air-tight requirements docs and processes and forces the business to use them; after the initial excitement wears off, weariness sets in; and once everyone realizes we’re not getting any better results for all the extra effort, we cut through all the “requirements red tape” and simplify the process; and the cycle begins all over again.

The best way to stop this swing between extremes is by structuring your requirements with use cases. There are a variety of approaches for doing so, but the one I’ve had the most experience with is Agile modeling using UML.

I’ll leave the nitty gritty details of agile modeling to the experts, but suffice it to say that the benefits of agile modeling with UML come from two places:

  1. Use of agile methods
  2. Tight alignment between business-facing and technology-facing documents in UML

We’ll get to the first in a later post on agile methods/approaches, but the second is directly relevant here. UML does a great job moving, step-by-step, from a description of a use case that the business understands to a description that BAs and SAs understand and then decomposing these into diagrams to be used to design systems and their interactions. And even if you don’t decide to implement all that UML has to offer, it can be scaled back to an appropriate level for your needs.

For example, I was running a SWAT development team responsible for bug fixes and weekly releases to our web properties. We were a hard-core waterfall shop, but we knew that waterfall methods wouldn’t work for us. I was lucky enough to have the world’s best BA working on the team, and he trimmed down the UML framework into a manageable subset for us:

  • Use Case Diagram
  • Activity Diagram
  • Interaction Diagram

With these three, we were able to strike the right balance between agility and control, and were well placed to use a tool (RallyDev) to help manage our SDLC.

At the end of the day, the particulars of how an IT shop puts structured requirements into place will vary. But my point here is that without the effort to do so, managing your demand pipeline (and may other core IT functions) will be more difficult, if not impossible.

In the next post, we’ll turn to look at how the mix of resources in an IT shop (BA, PM, developers, QA) affects its culture and the applications it delivers.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: