I’ve gleaned a lot of “nuggets” of wisdom about how I think IT should be done from my professional experiences over the years. These nuggets range over a variety of topics — people, communication, approaches, strategy, tactics. They never have anything to do with a specific technology or technique. Many nuggets have been picked up because I’ve observed things that worked. Many others have been picked up because I’ve observed things that haven’t.

Here are five of the nuggets I’ve found really helpful to managing IT, particularly when you’re doing something meaningful (a.k.a, hard, complex, big, visible, strategic). But first, two quick caveats. One, these nuggets have nuances. They aren’t meant to be applied in every situation or even the same way in different situations. Their usefulness is in provoking questions. Second, common sense applies. I’m not dogmatic with these and I don’t expect anyone else to be, either. If they help you in certain situations, great. If they don’t, then don’t use them. In all cases, use your big, powerful brain.

1) Success is dependent on people, process, technology — in that order
This might be the nugget I use most often. I am firmly convinced that the best way to ensure the success of something – anything – is to get the right people involved. Then define the process that works for those people. Then arm the people and support the process with technology that makes sense. If you’re not looking at the people first, you’re hurting your chances of success.

1a) A fool with a tool is still a fool
This is the first corollary to this nugget. You could have a great tool (a.k.a., technology, system, solution), but if that tool doesn’t solve the real problem, you won’t be any better off by using the tool — and in fact, could be worse off through loss of money, time, and credibility.

1b) Solving a problem usually only takes a few of the “right” people
This is the second corollary to this nugget. I believe solving a problem must address the people issues first. I also believe you don’t need to involve everybody in solving the problem — only a few of the “right” people are actually required. These “right” people are in the best position to effect a solution — the decision-makers, the money-controllers, the key influencers, the ones with the most passion for or knowledge of the problem or solution.

2) Consistently right, consistently wrong — at least it’s consistent
Do it one way. Or do it another way. But at least do it the same way every time. Consistency makes things easier to fix, improve, document, and communicate. Consistency through documented standards is great. Consistency through automation is even better. It’s much harder to make an organization better without the consistency you get through automation or documentation. I heard someone say once that without this kind of consistency, all you have left to get results is “undocumented heroics.” Not good for the long-term health of the organization. Also not good for the morale and work/life balance of those involved. Paul Duvall has an excellent post on automation’s role in DevOps – an area I’m really interested in because of its potential to make life better for lots of people inside and outside an IT organization.

3) KICASS — keep it cheap and simple, stupid
You’ve probably heard the “KISS” principle (“keep it simple, stupid”) before. I’ve refined it a little to add “cheap”, too. Just as complexity can kill an idea or a project, so can expense. Use available free stuff wherever you can, especially when you’re getting started on something. And “free” is relative to the person paying the bill (e.g., If corporate IT is paying for hosting, office productivity applications, and development software, that stuff is free to project managers in the business units. That stuff is definitely not free for the person managing the corporate IT budget.) I’ve seen a lot of organizations sink large amounts of money into tools and platforms up front, only later to discover those tools and platforms weren’t necessary or that there were better, cheaper alternatives.

4) If you’re going to fail, fail fast
This is another one of my favorites and I apply it a lot at the start of projects. I seek out the areas of the project with the most risk and attack those first. I want to eliminate unknowns as quickly as possible. If I’m going to hit an obstacle, I want to hit it early so I have enough time to change direction and still meet the overall objectives of the project. Finding a showstopper late in the project creates a crisis. I hate crises and would prefer to avoid them whenever possible. Smooth, boring, uneventful projects are much better for my sanity and work/life balance. Spend some time thinking about the risks inherent in the work you’re doing then use prototypes, proofs-of-concept, socialization (another nugget), and multiple alternatives (another nugget) to mitigate those risks. Your sanity and work/life balance will thank you. Eric Reis does a great job putting a lot more meat on the bone with this concept with the Lean Startup model.

5) Focus on the now or you won’t get to the later
Have you ever been in a situation where someone was strategizing about events and outcomes far in the future and ignoring the big, fat meatball of a problem facing them right now? Didn’t all that talk about strategy seem pointless at the time? Don’t get me wrong, I’m a fan of vision, strategy, and goal-setting. Those things can be really valuable if used appropriately. But it’s also important to focus on things happening in the present so they don’t end up making all that great vision, strategy, and goal-setting moot.

I have a lot more nuggets for various situations. Folks I work with get a kick out of them when I pull them out. Maybe they help focus the discussion. Or maybe they’re entertaining. Or maybe they’re just laughing at me. In any case, I’m always on the hunt for new nuggets, so share ’em if you got ’em.