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