Working with Large Organisations

As an answer to a small business-man asking what it is like to work within a large company:

 

"I have been thinking about the questions you had about working with large organisations. I have not worked with many *small* companies so please take this with a grain of salt but:

One major concern of ANY organisation of any size at all is holding itself together and keeping people working together. With small groups this is done instinctively through shared goals and constant reinforcement. The larger an enterprise gets the more effort must be given to maintaining itself as an organisation. In the largest global companies the vast majority of the effort is involved in management – which is another way of saying getting individuals to work together.

Hence: they tend to be very conservative about change. There will be a (great) number of processes, procedures, governance etc. – basically red-tape – to ensure everyone does things the same way. All of which is designed to make sure that complexity is reduced, higher ups have good visibility of what is going on through the murk, and no-body is going off on their own.

There is, of course, less of this the higher in the organisation you go until the board is generally able to try new things – except that board members tend to have moved up through the chain and well aware of the balancing act and the need to stay close to the centre.

In summary – you will find it harder to ‘get things done’ the larger the organisation you are working with. You may be able to mitigate if your interest is restricted to a sub-set of the company. A division will operate as if it were a smaller group – but always within the context of the larger processes with regards to things like Procurement, Financials, HR etc. [This could be an issue for your product since an ERP is, by the very nature of it, concerned with the entire enterprise].

The same basic circumstance applied in IT. Any new system will almost certainly require integration with a number of incumbents. The larger the company, the more sub-systems (often more than one doing roughly the same thing – decommissioning anything is difficult) and therefore the greater the integration overhead. This manifests in negotiation and tight specifications, combined testing, shared environments etc. – all of which add significantly to delivery timelines. And costs – which is why the figures I quoted are relatively high compared to the smaller companies you are used to.

As above, the overhead can be mitigated by restricting scope to a single function/capability. Staying highly coherent and loosely coupled (of course this is also good architecture). But make sure you are not overlapping functionality with some strategic system which is carrying out the same work for the company as a whole.

Finally, I should call out the problems that all this poses for Agile development. Trying to tweak a web-site which relies on a mainframe that has an annual release cycle is an exercise in frustration. Full end-to-end testing alone can be a major issue in co-ordination. It is better to decouple through an integration layer and let each piece operate at its own natural pace."