Tom Peruzzi's thoughts on digital, innovation, IT and operations

During my article about DevOps I started thinking about the way Ops projects work or should work. By doing so I came to the end that it is quite worth having a deeper look on it. In general you can differ between 3 types of projects within Ops:

• Business Projects delivering new functionality, driven and owned within Business
• Internal Ops projects, mostly new / adapted platforms, new ops or management platforms
• External Projects driven by Hardware or Software Updates, Security Upgrades and others

Doing so let’s have a look on how those projects work and what you need to deliver best:

Business Projects are – focussing on Ops – more Project Controlling and Coordination tasks than real Project Management, scope, timeline … is mostly driven by Business even if Ops had the chance to plug into that project very early. Thinking so it is very useful to have one person acting as a project coordination instance, triggering people, timelines … within ops, but not doing full Project Management, as this will fail. Thinking on that you will recognise that the Project Coordination Instance is cross functional over all departments of IT Operations, each department has to agree on time of their people being used and managed/coordinated by the Ops Project Coordinator. But it will help the Ops Manager, all his/her Head Ofs and the overall organization as projects will pass through more successfully being coordinated by one instance than being managed by the engineer itself.

Internal Ops Projects are mostly hard to cover as they are managed by engineers and, much worser, mostly don’t fit into focus of the company. To get this sorted the Ops Manager has to talk to the companies’ Steering Comitee (if existing) or communicate very early and clear the goal of the project to all related stakeholders. Remember: goal should not be the “much better” Firewall, it should be countable business value. If you are a lucky guy you will get a PM resource from another department or you have a very skilled engnineer within your department … but always keep in mind: Engineering is a skill, PM is a skill too, a very good PM engineer isn’t met that often and secondly your organization has to be able to support a PM entity (lot of you think you do but tbh PM means day2day transparency and most of us don’t like it in that detail, we often feel too genious to submit tasks and end dates and how and why we will reach that date …)

External driven projects seem to be driven easily but there is one major conflict that the release date from external will not fit within the maintenance window calendar of your organization and – much worser – the features which change don’t fit into your orga either or they potentially threaten exactly the one you use most … So keep in mind that even it looks like easy to cover you need to communicate very early and distinct to avoid later pain. Who’s doing that? In my personal view this is the only project an engineer can cover beside/within his normal operations tasks as it is mainly the most technical approach of changes within the IT landscape.

Thinking so the result is the following:

• get a project coordination instance in for all IT ops disciplines
• use internal/external PM help for larger IT ops projects if you have no extra skilled resources
• use your engineers for updating/patching if feasible and affordable by workload

Potentially you can keep on discussing and what I don’t want to mention in that article is the question about the right PM methodology for each flavour of projects or whether one would fit for all (most organizations tend to think so knowing that they all differ by > 80% …)