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:

Actually, he misses one of the main reasons the C&C pattern doesn’t even work for the military.

It all begins with the 1973 (no, seriously) Yom Kipur War between Israel, Egypt and Syria. Having taken Israel by surprise, the Syrian tank divisions storm through the Golan Heights and almost reach Nafah where the headquarters for the Israeli forces were located.

Had the Syrian forces reached Nafah, they would have most likely defeated Israel and conquered the Golan Heights at the very least. But they haven’t, and didn’t — instead, they stopped.

Just before overtaking Nafah (‘on Nafah’s fences’ as Wikipedia describes it), the Syrians halted their advance. This allowed time for Israeli reserve forces to arrive en-mass and overturn the tides of war, eventually costing the Syrians their victory. To this day, no one outside Syria (and maybe Israeli Intelligence) knows for certain why the Syrian force stopped so abruptly.

There is a prevailing theory, however. This theory boils down to the difference in management style between Arab armies (Soviet trained) and the IDF. Arab armies are trained for complete Command and Control management, an underling will not make a move without being issued a command. The most initiative he can show is to suggest a course of action to his superior, who might suggest it to his and so forth until the highest authority on the matter is reached, once he makes a decision the order to action travels down the chain of command. As any software engineer will tell you, this upstream-downstream transaction means very high latency.

Israeli military on the other hand, have an altogether different standing order: a soldier without immediate contact to his supervisor is his own chief-of-staff. This translates to initiative and rapid response during the fog of war.

So imagine that the Syrian tank brigade commander, having surpassed his superiors’ expectations and advanced so quickly into Israeli held territory that he exhausted his current orders. He was not meant to reach Nafah so quickly! As he is trained not to question his orders, and as he is only given very limited information (on a supposed ‘need to know basis’) he can’t assume that proceeding forward would fit with the larger plan.

Thus our well trained commander jubilantly radios back his headquarters and informs them of his brilliant success and requests further instructions. While his report travels up the command vine, he and his forces are minutes away from victory and are standing completely still.

The next step of the reasoning is quite clear:

Use a command and control management style and you will be the bottleneck of every development step, as every decision beyond what to call the class file will be relegated to you. This is not just hit-and-run micromanagement, this is a semaphore locked development cycle and is hardly an efficient use of your very valuable resources (otherwise known as: people).

While there are many (many!) number of arguments why C&C does NOT work for software development projects (for example: writing good software is a creative process, C&C management hampers creativity) I think the above is the most important and most direct argument against such a style of management.

Having said that, there are places where C&C is just fine.

Technorati tags: software-development, management

Bookmark to: