You are in charge of a project for developing an internal application at a large brick-and-mortar company. Your target audience for the application are the employees of a critical business department (here on, Department X). The customer representative is the head of that department and is glad to be involved in the planning process and domain knowledge sharing as well as story analysis, hand over and sign-off; Seemingly, an ideal ‘customer’, here on- Mr. X.

Yet at scope planning meetings for the project, Mr X. is insisting that all the feature requirements are ‘Must Haves’ and while he agrees that the order of development should be based on ‘higher business value first’, he refuses to de-scope any features, insisting that due to external circumstances their delivery must occur by the project’s go-live date.

You would accept Mr X’s proposal if he would be willing to increase the budget for project to allow resourcing to meet these requirements. Great! He is willing! But wait — he can’t. Why? Because the project is funded out of the IT budget and not out of department X’s. This is a lose-lose situation, as the project is now set to fail in the eyes of the customer and in turn, harming the IT department’s reputation – Department X is not getting what it wants, even though it is willing to pay for it. 

The root cause here is the divergence between the beneficiary of the application and the entity that pays for it. The two may have differing goals, priorities, political considerations and machinations and whilst they both work towards the same organisational goals, these two entities operate under different business units with sometimes divergent operating considerations.

Budgeting models for IT departments seem to be based around IT as infrastructure — which makes sense for, wait for it… infrastructure: network, VOIP, hardware and the like — but repeatedly fails for business applications.

While it makes sense for IT departments to harbour the core capabilities and knowledge for software development (….development infrastructure…) it should only act as a cost-effective contractor to the business when developing business applications. Business applications projects should only be undertaken as part of a business case, they should have clear ownership by the benefiting entity and not the IT department.

When analysing teams and projects that clearly ‘smell’ and have a hard time changing, my personal experience indicates that in the majority of cases, following the smell to its source leads to this root cause. This is more pronounced in bigger organisations and seems to be proportional to the level of organisational separation between the project beneficiaries and the IT department. More so — this is almost always the underlying organisational issue that makes it difficult to implement agile methodologies.

This lesson was learned by many organisations, but unfortunately not all — and it should–

 The ‘IT department pays’ model of application development should die.

Bookmark to:

Why? Because while sitting at the airport waiting for my flight I hear that every time they page for late passengers there are always Israeli names included, always. Do you realize how small the percentage of passengers are Israeli? Yet they are the star of the show when it comes to rampant disregard to anyone aside of themselves.

Passengers Vardi, Shavit, Egoz, Ronen and co., please get your lazy asses out of the duty free store and onto the bloody plane on time!

Bookmark to: