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

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 third, developer-heavy staffing.

When I talk about developer-heavy staffing, I’m referring to the application development area of IT rather than network ops, service desk, and so on. Given that, the application development function of an IT shop has a couple of main buckets of resources: business analyst (BA), project manager (PM), developers, and quality assurance (QA) folks. The balance of these at any given organization is a fairly accurate indicator of the health of the app dev function there.

And rather than going through all the possible permutations, I want to look at developer-heavy staffing in particular, both because it’s very common and because it’s particularly damaging to the ability of IT to deliver value to the organization.

Now, before I get embroiled in the nitty-gritty details of developer to tester ratios and all that (which as usual I’ll leave to the experts), let me say that my approach is much more gut check than quantitative analysis. Really what I’m advocating is that you take a look at the app dev function and ask yourself some questions:

  • Is IT responsible for BA work? If so, is there a dedicated BA organization/team in IT? If not, who is responsible for BA work? Scattered folks throughout IT? Business resources? Outsourced resources?
  • Is IT responsible for PM work? If so, is there a dedicated PM organization/team in IT? If not, who is responsible for BA work? A non-IT PMO? Scattered PMs throughout IT? Business resources Outsourced resources?
  • Is IT responsible for development work? If so, is there a dedicated app dev organization/team in IT? If not, who is responsible for app dev work? Scattered folks throughout IT? Business resources? Outsourced resources?
  • Is IT responsible for QA work? If so, is there a dedicated QA organization/team in IT? If not, who is responsible for QA work? Scattered folks throughout IT? Business resources? Outsourced resources?

The answers to these questions start to give you a better understanding of what issues an IT shop might be having with its app dev function.

What we see in developer-heavy shops is that what comes upstream and downstream of development is woefully understaffed or out of IT control (or a mix of both). Rolling some combination of the BA, PM, and QA roles in a single resource (sometimes all three at a time), having PM and BA roles in one resource and the development and QA in another, or just having far fewer BA, PM and QA resources relative to development resources are all typical outcomes in a developer-heavy shop.

The result is some or all of the following problems:

  • Requirements gathering – shortage of BAs (or BAs who also have to wear PM or QA hats or both) can lead to suboptimal requirements gathering
  • Release quality – the high developer to QA ratio makes is difficult to bring QA into projects from the very beginning; often their resource constraints make it more typical to get involved for the first time very close to code drop
  • Time to market – errors made during requirements gathering are compounded by the downstream impacts of the high developer to QA ratio
  • Project controls – budgeting, scheduling, and estimating are all more difficult, whether because the PM function is less robust or because of the difficulties predicting the downstream impacts of the high developer to QA ratio

It’s also more likely in a developer-heavy shop that the SDLC will be waterfall, as more agile methods have more robust BA and QA functions baked in…and therefore lend themselves to more balance between all the roles in app dev.

Now, I haven’t brought in some other non-developer roles that you might have at an organization, such as enterprise architect or systems analyst, but the principle remains the same for these (or other) non-development resources: their numbers relative to developers have a profound effect on the overall health and effectiveness of the IT function…and ultimately of the organization as a whole.

In the next post, we’ll turn to agile methods and approaches, but for now, I’d love to hear from folks out there who want to share their experiences and opinions on the matter of staffing–let’s get the conversation started…

Advertisements

2 Responses

  1. Great post Joe… another item to consider is the higher cost of a developer-heavy IT organization. In my experience, a developer /programmer tends to command a higher hourly rate than a quality assurance analyst or a business analyst. In an organization which lacks proper QA staffing, the developers are expected to do more testing prior to handing off their code to the Business for UAT. First of all, this increases your QA costs as you are paying a higher rate (developer rate vs. QA rate). Second of all, (from my experience) developers tend to HATE testing so the quality of their “testing efforts” is pretty poor. This leaves the business users of the application with the responsibility to ensure the product is bug free and stable (and we all know how busy the business users are).

  2. Excellent point, Jolanta–one I hadn’t even thought of, but you’re absolutely right.

    Thanks for getting the conversation going!

    Joe

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: