Yes, but what do they really want?

One of my favourite personal complaints is that I cannot read minds.  Of course, if I could, I would be tarred, feathered and railed into radioactive slime for a slow 'orrible death for, in this Facebook age, who wants their last barrier violated by the sys admin?

Recently, I got a good chewing out from On High because a network improvement plan I was executing was seemingly making things worse. Whether or not this was true is irrelevant; On High felt it was true and any defense is, well, just being defensive. Cred fail.

The main problem was communications, never a hard-core tech-oriented sysadmin's best talent. Although I was following the overview I had sent to the boss, I had no guarantee he actually read the work breakdown.  Not only that, I had failed to take into consideration what the end-users and their chiefs felt were the priorities. I was pursuing priority a (a wiring closet that had too many trunks to other wiring closets) when the users' most vexing problem was priority b (replacing statically-assigned workstation IP addresses with dynamic DNS; the former was impeding movement over subnets).

The standard method to mitigate this issue is, of course, setting a meeting. The reason for meetings is to find out what the users want, what IT is doing, how it all translates into business terms, how it translates into IT terms, and (hopefully) the beginnings of an improved and better-publicized project plan. A plan that is agreed on by all parties has a high chance of success, everybody on all sides wins, and the admin's cred goes back up.

Meetings should be short. The agenda should also be short and consist of the following items:

1. What needs to be improved?
2. Why does it suck and how does it affect the business?
3. What's the degree of suckiness? (impact)
4. What is already being done to reduce the suck?
5. How long can the suckiness be tolerated? (i.e. project close date)
6. When can we meet again to discuss the plan?
7. Immediate solutions that come to mind (brainstorm)

The next meeting should be with the boss and your colleagues and held once you have done your research on a solution. The agenda, once again, should be short, and an overview of the strategy to be followed already set up in a document on the projector:

1. Introduce the issue
2. Introduce the solutions
3. Agree to a solution or table solutions for cost analysis
4. Agree to the next team meeting.
5. Identify stakeholders: all those affected by the change (hint: the boss, dept heads, team members, testers, suppliers (even those not supplying the project per se), users, possibly general public)
6. Set up a skeleton communications plan
7. Set up a skeleton equipment and purchase list
8. Identify time and team-member constraints (really important since, for example, you don't want an unstable network during a trade show)
9. Identify other projects affected by this one
10. Set up next actions

"Set up next actions" is dangerous. It does not mean coming up with the entire work breakdown structure (WBS) set up in an GANTT chart. It means each team-member who has something to do agrees to do at least one task. This may be, in fact, brainstorming a WBS but it may be also be as mundane as writing a draft plan announcement and sending it to the boss for vetting.

Also note that setting the next meeting happens before any brainstorming. In my case, my team has regular meetings anyway so it is not a requirement unless it is busy week for operations.