In my first post on the subject of developing a business case, I discussed the importance of defining objectives, and not just in terms of server counts, but factoring in costs and organisational structure. In this post, we’ll look at stakeholders, not just identification, but how to manage them and what considerations need to be given to make Discovery a success.

You have an executive mandate and – hopefully after much deliberation over the precise costs and benefits – you have executive approval, but at this point, who else in your company knows? The answer is usually no-one. During my time as a consultant, usually the first anyone below executive level had heard of the project to implement Discovery was when I approached them for information, change approval or even sign off. As you can imagine, this has the potential to lead to considerable delays as you go through the ’20 questions’ routine – where were these people when the workshop was taking place?!

At this stage let’s be honest, it’s not unheard of for a solution to be brought in as a pet project of an executive director, or to replace another tool, or even a deal made at the golf course. This is hardly the fault of the vendor or a mark against the solution itself, but nevertheless these scenarios can lead to a degree of hostility towards the new solution and the project team. In one short project which required access to a number of database solutions (part of an enablement of a migration away from those very products), I had a sysadmin who ignored all my emails and phone calls until the last week of the project. He then proceeded to email the project board to complain that I was inexperienced and had not given them enough time to provide the information requested. Thankfully, on this occasion, the team manager had my back; I wish I could say that was always the case, but when it isn’t, it can then backfire in a very gradual way. If a project team starts to see themselves as undervalued and under attack, before you know it valuable resources will be leaving your company and in turn your project high and dry, taking their knowledge and experience with them.

Discovery can potentially impact everyone – because it is potentially touching all aspects of your infrastructure – hardware, software, databases, networking… Therefore, everyone in your company is a potential stakeholder.

Even where communication has gone out, and the project methodology has been defined, it’s rare to find that it has been followed through to the extent that it needs to be. Basic things like nominating a senior user and end-user handover can be completely forgotten until the project is well underway. It’s important than, that even if not all stakeholders are not considered or consulted when bringing in a new product like Discovery, effort is put towards linking the desired outcomes to the roles required to effect those outcomes. The list of considerations below are by no means exhaustive, but should be reviewed as a minimum, to avoid costly delays and re-scoping:

Company Culture

• Do you’re employees embrace company goals? Are they aware of the latest technology trends? What is their ‘risk appetite’ and attitude towards change? The answers here are going to be important for determining how to go about building acceptance and formulating your communication strategy.
• Is your organisation flat or operate several layers of skills, experience and management? Do workers report to the same people who are line managers? Will communications and mandates from high executive level above filter down to the implements, or get lost in the fog of management layers?
• Does your company operate informal, open-door policies, like a ‘family’ – or is it formal, procedural and authorisation based?

It should go without saying that the more formal, procedure-based and layers of management that exist in your organisation, the longer it will take to get a solution rolled-out. It is also likely that they are change averse and may require some kind of risk assessment. The important thing to realise is that Discovery can potentially impact everyone – because it is potentially touching all aspects of your infrastructure – hardware, software, databases, networking… and feeding all that into your ITSM processes. Therefore, everyone in your company is a potential stakeholder.

Building Acceptance

• Have your cyber-security team reviewed the impact of Discovery? Are they aware of the project and it’s implications? Do they require any specific auditing such as ISO27001?
• Do the objectives for Discovery (e.g. to replace another tool) impact your employees or users? Even if Discovery is only part of a greater enablement project to replace other tools, employees whose work and skills are tied to those toolsets will be motivated to see it fail, and be likely to raise as many objections as possible, regardless of merit.
• How will you get buy in to the project? How will you reduce bureaucratic stonewalling? Are the benefits clear? Often times resistance can be overcome by identifying indirect benefits or even opportunities through extension of Discovery. Nobody can complain if you can demonstrate how the discovered data will make their jobs easier.
• Do the end-users have a choice in using the Discovery product when all is said and done? A tricky question if you’ve already made a license commitment, but if you’re only putting it out as one of several alternatives (particularly if those alternatives are already installed) it will be a use-case failure, even if your implementation comes in under budget and ahead of schedule.
• Is there a cost for non-compliance? Who will be billed for success/failure? There will be little interest in rolling out a new tool for existing infrastructure where there is no accountability for saying no. Similarly, no-one wants a bill sent to them for something they didn’t request, and didn’t budget for. This should be factored into the communication strategy.

Security is a key aspect here – making an expensive license commitment only to find that half of your (assumed) benefits are wiped out by strict security policies is a costly exercise. Ensure cyber-security are consulted before you sign the deal; ensure they are satisfied with the product – or that you raise/authorize the necessary exceptions. A solution like BMC Discovery is a secure and proven tool, but the degree to which it captures data and the large amount of ports used rightly makes some security heads nervous, and they can be unhappy if left out of the loop at initiation.

Communication Strategy

• Is the deployment of Discovery organisation-wide, or limited to selected business lines, customers or accounts? The larger the project, the more the onus is on leadership to communicate and spread awareness of their mandate.
• Are there clear lines of escalation? It seems awkward to consider the escalation process before you begin, but you’ll be thankful for a clearly defined process when (yes, I said ‘when‘) you hit that inevitable conscientious objector who knows everything they need to know about the domain they manage and they don’t need Discovery thank-you-very-much.
• Are your project team and infrastructure people onsite, spread out among locations, or completely remote? Do they work in different time-zones? Time zones and remote working are going to increase the timescales you need to work with but they’re also going to slow down communication.
• What communication tools will you have at your disposal? What are the most effective? If your company has access to social messaging and social networking tools this could cut down on unnecessarily large email threads and distribution-lists (both of which tend to get ignored).
• Who needs to know and what do they need to do? There is a tendency on large projects with lots of teams to hold meetings with up to 100 people in attendance, where possibly only 10 are needed. Larger meetings tend to create an ‘audience mentality’- if participation and discussion is necessary then keep the meetings small and split them up.

If you’re working across timezones, you should bear in mind that some regions have a work-culture that means employees will down tools at 4.55pm and be out of the office at exactly 5 –  this can lead to at least 18 hours before receiving a response to even a simple question (assuming they even have the answer)! it seems ridiculous but this can mean getting agreement on even minor technical details can take weeks if it involves coordinating with several people across the globe.

Meetings need to have clearly defined agendas with owners and actions. Sometimes scheduling regular progress meetings can keep people on track, but if the meetings are undefined with no-one chairing or no decisions to be made, then some people may choose to skip them altogether. Before scheduling a meeting question what the desirable outcome is, what decisions need to be made otherwise it’s really serving no purpose but as a time-vacuum. PM’s need to be bold in holding people accountable and defining decisions taken, actions, owners and deadlines.

Finally, for a global deployment, effort should be made to publicize the project via company newsletters, managerial meetings and any other communication channels. Don’t just leave it to the project team to approach the whole organisation out of nowhere. Most likely your project team will be made up of employees new to the tool or the company, and possibly one or two external consultants. new employees and contractors will be inexperienced with your company culture and hold little to none of the political capital needed to ‘get things done’. Similarly, a vague project mandate dictated from the clouds above holds little influence over developers and sysadmins at the coalface – communication needs to be clear, authoritative and backed by measurable outcomes or consequences.