Who’s payin’ the bills?, or “How to drive a stake in the ground”

We’re in a bit of an odd place with our project now. We’re behind schedule, yet the development team has little to do. But we can’t call our tasks done because they haven’t been tested and approved. In short, we’ve hit the grey area of software development called “process”.

I’ll skip the lecture on bottlenecks because I didn’t do very well on the Operational Management course in university where I was first introduced to the concept formally. Instead, let’s focus on one of the factors that led to it.

The project I’m on now is an IT initiative. That is, it was the IT departments idea to create a bunch of applications to replace old ones. As such, the IT department is footing the bill, not the business. Yeah, I heard those some bells when I first discovered that, too.

Now, I’m not privy to the factors that led to this so it would be judgmental of me to comment on why the decision was made. What I can talk about is the effect of it.

In a typical scenario, when a feature comes up to be developed, there are inevitably choices to be made. Should we use a dropdown list, which is easy but cumbersome? Or a look-ahead textbox, which is easier to work with but harder to develop? If I’m the business and I’m not paying the bill, the choice seems pretty obvious to me. You go with the one that looks nicer.

That’s the obvious problem. There are more far-reaching ones. Because our client doesn’t have a financial stake, the project isn’t a high priority. They have their other regular day-to-day duties to attend to; coming up with functionality and test plans for us has to be fit in where it can. If it doesn’t fit in, well, then we can deal with problems in testing. What does it matter if we have to send it back to development because it doesn’t meet our needs?

This is not the fault of the client, mind you. This decision process I described is natural and, in fact, healthy. They have goals and expectations to meet. This project is actually an impediment to those goals. Every time I ask them to clarify something and they respond with “I’ll take a look when I get a chance”, I’m disappointed, but I can hardly blame them for it.

This has almost inevitably led us to our current situation, where we’ve been humming along with the development, but are not delivering value to our full capabilities.

So the moral of the story, I suppose, is to ensure the person you’re building for has a high enough stake in the project. Seems like obvious advice but it can easily be overlooked. Maybe you have some downtime and want to use the opportunity to train up your staff while still delivering something. Maybe you need to retire old applications because they are hindering an infrastructure upgrade. Maybe the bureaucracy is such that you *really* want to update the old apps but you’re meeting resistance from the rest of the organization. You may have noble intentions but don’t forget your own budget.

Kyle the Stakeholder

This entry was posted in Sundry. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://codebetter.com/members/kylebaley/default.aspx Kyle Baley

    I don’t want to guess at what the impetus for this was. Maybe there is a legitimate enough business reason. And the business has been nothing less than encouraging throughout the whole thing. Perhaps incremental improvement may have been feasible (though given they’re VB6 applications, I suspect not). It doesn’t really matter. The underlying point is that whatever direction the IT chooses to take, the commitment from both sides should be spelled out clearly (maybe even contractually) at the outset.

  • Steve Py

    Exactly my take on the situation. Unless you prove value to the customer, any initiative you might personally justify in a project will most likely not be welcomed by clients. (Look at how much difficulty Microsoft has trying to sell new versions of Word, or even OS’s lately.) Heaven forbid you actually “break” something, even if that is a change in a way they feel is less usable.

    It’s frustrating to try and adopt new technologies etc. in existing projects. No one wants to spend money on it unless there’s a sure benefit. (Beyond developers keeping their resume’s current:)

    Generally my approach has been to factor in incremental improvements. As updates get released I like to make subtle improvements and do the ol’ optometrist: “better, or worse?” before I aim to consider rolling more widespread changes out. I factor those improvements into my estimates. :) Steve’s “Window Repair Tax”.

  • Nelsona

    So basically, the IT department decided that they wanted to rewrite applications that the business users had no real issues with…

    I have been in this situation and it never works, the business has no buy in as they do not see a reason for the change.

    When it comes to changing applications used by the business, they should be the drivers not the IT department.

  • http://codebetter.com/members/kylebaley/default.aspx Kyle Baley

    Assuming I’ve parsed that correctly, yes, that is one scenario that could lead to a similar situation. In our case, we (and perhaps I’m using the royal “we” but I’ve seen no evidence to the contrary) aren’t so arrogant as to believe we have the authority to prove anything. I wasn’t involved in the initial project plan but I suspect it went more like this:

    IT Department: “We’d like to redo all these applications at our expense and as our customers, we’d like your support in ensuring we do it properly.”
    Client: “Aw, that’s sweet. Sure, we’ll help in any way we can.”

    …without anyone quite realizing what that would entail. Myself included, by the way, because as obvious as I’ve made it sound, I don’t want to imply that I saw this coming. Just observed its effects after the fact and added it to my cache of life experiences for next time.

  • http://codebetter.com/members/ScottBellware/default.aspx ScottBellware

    Maybe the problem is rooted in the belief that the making of the software and the proving the what was made does indeed work are separate parts of the workflow done by different people at different times.