Defining what successful operations look like is different for every agency and program. There are different levels of operations, of course. There’s network availability, network security – there are the nuts and bolts-type IT measurements that are taken continually. There are metrics around progress on configuration management changes tracked through tickets – are the tickets being closed on time, etc. And there are SLAs and KPIs built into our contracts. 

But, whether it’s IT or program operations, the bottom line is, are you getting the outcome you wanted from the work that’s being done? 

Successful operations are defined by meeting the metrics you set for success on the front end. Success at the first level is getting the whole team invested in achieving the same goals using the same measurements. Success during a project is more than just meeting milestones; it is also having a clear plan for how to get back on track if there are delays or other unanticipated circumstances. You’ve had success at the end if you have met your metrics AND everyone feels good about what they accomplished. 

How do you get there? For me, regardless of the intended operational outcome, there are a few key components to any successful operations and maintenance program that I come back to time and again. 

•    Stakeholder Engagement: I view this as “Step 1” toward a successful operations program. It’s about getting a program off the ground on the right foot by doing the due diligence to both understand who the key stakeholders to an implementation are, and what the specific needs of the areas they serve are. Then it’s about getting everyone bought in. Failures happen when a key player has been left out of the conversation or doesn’t feel comfortable and in agreement with the direction a program is heading. Getting the right people around the table and talking openly is key to rowing in the right direction. 

•    Transparency: Transparency is critical to effective communication. My teams hear me say all the time, “Sunlight solves everything.” This isn’t to say that the nuts and bolts of the implementation itself aren’t important, because of course they are. But managing risk, delivering on schedule – all of those nuts and bolts sit on a foundation of forthright and open communication. Surprises are rarely, if ever, a good idea. 

•    Security: Security is never NOT important. It’s especially important when dealing with tasks that are high-risk and/or mission-critical. I’m often caught saying, “IT security is everyone’s job.” There are the standard things we do – security training, compliance training – all the fundamentals. But on top of that, it goes back to how you operate on a day-to-day basis. It’s speaking with my management team about security as a regular, repeating topic, and discussing it in a way that reinforces how critical it is to everything we do – in a way that makes it a priority of everyone’s job. It’s speaking in a way that helps people see the bigger picture of why security matters and our responsibility in supporting that. 

•    Commitment: This is a big one. Total and complete understanding of the ultimate mission we are trying to achieve as a team, and what role each function has to play in the overall delivery – is of critical importance. It’s not just commitment to the individual job or task. It really is so much bigger – it’s commitment to the larger team, the contract, the client, and our country, really. We’re talking about government missions, so the work we do has an ultimate impact on our citizens.

•    Empowerment: I reference empowerment in two ways: both ensuring that team members feel free to share their ideas around a specific challenge and in terms of the larger mission. Working collaboratively also helps protect against that age-old problem of decisions being made in a vacuum with unanticipated consequences for other areas of a project. 

•    Communication Style: We don’t go into conversations about planning and the future with an attitude of “you need to,” “you have to,” “you should.” That doesn’t help because it’s too prescriptive. Rather, I view our role and where we’ve had success by listening and asking information-gathering questions. Then letting our clients know we understand their challenges and that it’s our job as their industry partner in this process to provide them with some options to consider as they start to think about how to tackle a given problem, or start to develop as strategy around moving away from a system, tool, process, etc.

I would add that no matter how many milestones we set for ourselves on an operations project, it’s the non-tangible, softer-type skills like communication and engagement that make all the difference between an implementation that was done correctly and one that I would consider a success. 

The non-tangible part is the most important: it’s the people. Teams don’t just go away when a project is over. You finish a project and often go on to the next effort together. The successful team efforts are crucial to the operational longevity of the entire program.