Projects and operations

I'm stealing this topic from a posting I read on the internet. I don't know the source, though. I thought the source was from the "Keep the Joint Running" blog, but I see no trance of the idea. (Which doesn't mean it's not there -- it means that my search may be incomplete.)

In the realm of IT, there are two different worlds: development and operations. For this discussion, I am using the larger meaning of "development", the meaning that includes analysis, design, coding, and testing.

The two worlds are different, yet perhaps not as different as one might think.

Let's start with the definitions "an operation is a set of tasks that are performed repeatedly, usually on behalf of a set of users", and "a project is a set of tasks that in the end results in a change to the operation". These definitions lead to very different approaches to the management of development projects and operations. Development is a one-time effort, often requiring intense analysis, intense coding and debugging, and intense testing phases. But when it's done, it's done and the development team can kick back and relax. Operations, on the other hand, is a round-the-clock effort to keep things running. Rather than change things, operations strives to keep things from changing. The operation teams make every effort to keep systems up and running, keep systems available for users.

Yet seasoned operation managers know that change happens. Not just the updates and fixes that are inflicted upon them by the development team, but updates and fixes inflicted upon them by all of the development teams for all of the software and hardware that they use. (Think Microsoft's "update Tuesday", for starters.)

These updates are projects. Small projects, compared to the analysis-design-code-test projects of the development teams, but projects nonetheless. They result in a change to the operation. Security fixes result in new versions of components in operation. Updates to virus-scan tables result (usually) in more secure virus-checking systems.

The operations folks run an operation, but also handle projects (even if they don't think of them as projects).

Meanwhile, the development teams think that they are working purely on projects, yet they have an operation. An outsider will see this easily. Observe a development team for any length of time, and you will see that they perform the same actions repeatedly: attending meetings, sharing information, preparing documents, coding and debugging, ... this is the "operation" of the developer.

The mindset of an operations manager is quite different from the mindset of a development manager. The operations manager strives for continuity. Naive operations managers attempt to block all changes. Experienced operations managers recognize the need for changes and create plans to introduce changes with a minimum of risk.

Development managers strive for deliverables but not continuity. The focus on deliverables to the exclusion of all else serves them poorly. They introduce change but manage risk poorly. Don't believe me? Look at the numbers for development project overruns. Compare them to the numbers for operations. Development managers may think that they are managing risk but the numbers tell the true story.

Development managers  may benefit from the wisdom of operations managers. The development managers are leading an operation, and while it does not have tape drives and printers and weekly backup jobs it does repetitively perform a set of tasks.

The Agile Programming methods, with their use of short development cycles and automated tests, have learned from operations managers. Agile Programming treats development like an operation and strives not only to keep the produced code in a state that can be delivered at any moment, it also strives to work at a sustained pace. These notions are second nature to the operations manager.

If you want to improve your development team, look to your operations team.