Apple AirPrint on a Lazy Sunday...

So as in all things, it started with a question: "Why can't you print from your iPad?".  The most innocent of questions from my very smart fiance, and at first I thought it would lead me into a couple of hours of my favorite hobby... spending all afternoon doing with Linux what most people do in 10 minutes with Windows or OS X.  But in this case, I was happily surprised.

You see, my home infrastructure is all Linux, of a variety of ages, and on lots of old recycled hardware.  This includes my non-AirPrint capable, but fully functional network attached HP Officejet 7310xi.  I've not been able to print from my iDevices to this before, but then again I never really tried.  Shockingly, it took about 5 minutes of searching on the web and about 5 minutes to tinkering after reading various instructions, but it works like a champ.

The system I was playing with happened to be a CentOS 5.5 system that already had CUPS configured to print to my network attached printer and has avahi (the free implementation of Apple's Zeroconf architecture) installed.  So all I had to do was:

• Download this script and run it, which generated an avahi configuration file for each printer I had in CUPS;
• Move the file for my printer into /etc/avahi/services;
• Edit /etc/cups/cupsd.conf and add the following lines:
  
  ServerAlias * Port 631 Listen /var/run/cups/cups.sock
  BrowseAddress @LOCAL
   
• Add the following line under the   section:
  
  Allow @LOCAL
  
• And remove a  Listen localhost:631 line.
• Then restart both the avahi-daemon and CUPS daemons:
  
  sudo /etc/init.d/cups restart
  sudo /etc/init.d/avahi-daemon restart

And lo and behold I could print from my iPhone and iPad... as could the rest of the family from their iDevices.  And I discovered that my printer that I've had for years does duplex!  Who knew!


-- As always archives and originals of this blog, as well as the ability to comment can be found at Random Amateur.

Good, Fast, and Cheap... Pick Any Two

I've been a consultant, IT architect, project implementor, and project manager for many years.  Some days I think too many... mostly because I keep running into the same key project mistake over and over.  And its not just from the younger generation coming into the field, but from our peers and leaders as well.  Its this tendency to make the same mistake we saw 20 years ago that I find the most detrimental to project and business success.

To understand what this project mistake is, let's examine one of my favorite project maxims: Good, Fast, and Cheap... Pick Any Two.  Imagine you have a triangle.  At each point is a quality you want in the project you are envisioning:

• Good: embodying quality, meeting all your business needs, building for the future, bug free, is stable and works reliably...
• Fast: quickly deployed, completed ahead of schedule, shows results now, increased delivery speed, a more rapid return on your investment...
• Cheap: inexpensive, under budget, no project cost overruns, strict cost containment, costs translate directly to results...

Now it should become very clear (or will in a moment) that when it comes to projects, that getting the full measure of all three factors is nearly impossible.  And yes... I am considering these as "all or nothing" for the purposes of example.  I'll discuss using a sliding scale on these factors a bit at the end, for the purposes of a balanced argument.

On our "all or nothing" scale, lets say your project needs to be Good and Fast... which in my head translates to a rapid deployment of a quality product that meets the needs of your business.  The presumption is that Fast in this context is less time than a project of this magnitude would normally take, possibly with a rapid start.  So to mobilize the resources in quantity to complete this project faster than normal would mean we sacrifice Cheap on the project alter.  A relevant example is when Apple wants to crank out a million iPhones in short order to meet an unexpected increase in demand, they don't want to sacrifice their product quality (Good) and they need them right now (Fast)... so they pay for that.

By comparison, if you wanted Fast and Cheap in the above context, what would be left behind is Good.  You would get a product that possibly is not all it could be, has fewer features, is not as elegant, and could even have bugs or faults since testing time was minimal.  But you didn't pay a lot for it... so you got what you paid for.

Our final combination is of course Good and Cheap.  You want quality, craftsmanship, and a product that meets all your business needs, but you don't want to pay a lot for it.  So what gets sacrificed is Fast... you can't have it now... or tomorrow... or anytime soon for that matter.  You will get it, but no overtime, retooling, or possibly even dedicated resources will be seen in this project.  But in the end it will be a gem... but by then your competition could have passed you by with something not as good that came out a year earlier.

Now we know the world is not always "all or nothing"... and it is recognized that we have been talking about extremes on the project implementation scale.  It is possible that you could strive for Good and Fast and attempt as much as possible to ease back towards Cheap.  Just know that you won't get all the way to Cheap, and every decision you make to ease closer to Cheap will chip away at either Good or Fast.  Consider it a sliding scale and if you started with a 100% Good and 100% Fast project, then started to try to increase Cheap from 0%, you would pull one or both of the other factors off 100%.  Think in terms that you have 200% budget to spend on all three factors, and no more.

This is most evident in projects in crisis, since that is where changes are more dynamic.  Say you started with a project that was an acceptable balance of Good, Fast, and Cheap with probably more emphasis on Good (75%) and Fast (75%).  Then something went wrong: daily meetings were called, troops were marshaled, extra resources engaged, extra meetings over slippages and requirements conducted, etc..  Don't expect that by changing the game that the factors won't change.  Something as simple as daily meetings which tie up your resources for an extra hour or two each day to force them to make progress on the project or to cut through communication problems will very quickly blow Cheap out of the water.  In this case, you might go from Good (75%), Fast (75%), and Cheap (50%) to something more like Good (90%), Fast (70%), Cheap (40%), Good is considered to have effectively increased due to the daily meetings, which were meant to increase quality on the project through increased communication.  That was your intention right?

In the above example, let's say your project cost $250,000 and was 1 year long.  If a slippage like this happened and you were not able make up for it later in the project, given the above changes in ratios you might see a 25% increase in cost and a 7% longer project.  Some might think 25% is a huge cost increase, but consider that projects in crisis are rarely under budget or ahead of schedule to begin with, and once slippages start it is extremely hard to keep future activities from also slipping, let alone pull them back to being on time.

Now this brings us back to our key project mistake.  The above examples lays out the effect of decisions on projects and how something always gets sacrificed when changes are made.  That is where the key project mistake happens: thinking that a change or decision, even a seemingly minor one, will not materially impact your project.  Throwing a task assigned to your staff to the vendor, calling daily meetings that were not planned for at the beginning of the project, changing initial requirements, even something that seems as small as delaying a meeting from this week to next because "everyone is busy" will have an effect.  A project is an interconnected system just like the human body.  A project expects things to happen at certain times, and when they don't bad things happen.  If you skip lunch, you become cranky.  Its the same for projects.

How cranky is your project?

-- As always archives and originals of this blog, as well as the ability to comment can be found at Random Amateur.

ITSM Project Athletes

In a post from my company a ways back, it refers to Dead Money and how it impacts organizations.  Dead Money, according to Gartner, is the eight out of ten dollars companies spend on IT.  Its called this “because, while it is keeping the lights on, it isn’t directly contributing to your business growth or enhancing your competitive advantage.”

So I started thinking about how do we address some of the pitfalls in ITSM projects that are contributing to the zombification of your IT resources and operating revenue?  As we have all experienced, never getting an ITSM implementation past its initial phase causes it to not reap business benefits that exceed the expenditures that are made.  In other words it never lives up to the promises that are made in the sales cycle.

In my reading I came across a discussion of the qualities that make up a great athlete.  A great athlete or a sports team is not much different than the individuals that you bring together as part of your implementation team, whether they are your leadership, employees, vendors, consultants, or sub‑contractors.  In my many years in the ITSM implementation space, I’ve found that project teams who possess qualities similar to great athletes deliver successfully, reaping business value that vastly exceeds the initial investment, and continue to innovate rather than contribute to zombification.  Adapting the great athlete’s qualities to our project team we have: 

• Confidence, Skills, and Preparation: Through careful preparation (e.g. documenting the requirements and design) and the assembling of the right skill sets, a project team gives off a form of confidence.  This confidence has a foundation in the participants good work habits and the project’s constant progress towards a clearly defined goal.  When the project team is all working together, they share this confidence and trust in each other to accomplish their individual tasks, much in the way that all players on a field trust that they each will do their part when the ball is snapped.   All projects have problems or challenges, but utilizing this foundation, a “go for it” attitude, and being unafraid of failure allows the project to weather the unexpected.  When the project succeeds, the team will know it’s because of the effort they put into preparation. 
• Continuous Improvement: Successful teams bring an enthusiasm to continuously improve, not just today, but from the start of the project to the end… and beyond.  A project is not just an opportunity to execute the plan, but it’s a chance to innovate along the way and to create something better than anyone expected would result.  It’s a project team’s duty to foster and encourage this.  When a missed opportunity to improve is seen, it is every team member’s responsibility to point it out, no matter their role.  It’s also every team member’s responsibility to be able to accept this correction and look on it as an opportunity to learn and grow.  A good team knows to take correction as a compliment and look at it as an opportunity to improve, not an opportunity to respond with an excuse. 
• Investment and Pride: Through investing hard work in the project, every team member seeks to make something better for themselves, their project team, and the business as a whole.  The results of your efforts deliver a sense of pride and accomplishment.  In great projects, striving towards this sense of pride involves a desire to deliver as high quality work as possible, both for yourself and your project peers.  No short cuts, no jealously, no hording assignments, no entitlement, and complete accountability for your part in the project.  This pride is developed in parts of the project that require more effort than skill, where determination to succeed is more important than the technical and business skills the team members bring to the table.  It’s in the long hard nights of work, and in how the team picks itself up and dusts itself off after a setback, rather than wallowing the problems all project face. 
• Accountability: Great project teams and their team members take personal responsibility for what happens during the course of a project.  When things are not going well, team members look to see where they can make a difference and where they can pitch in.   Great project team members demonstrate that they are problem solvers, are cool under pressure, and are more likely to succeed than fail in the face of adversity.  Have you ever been on a team where someone blames everyone but themselves for project problems?  The only way a project can succeed is if individual project team members strive towards success, continuously improve, and work to the benefit of the project.

In working on a project, achieving the personal qualities that will allow your business to deliver success is all about choices.  Will you and your project team choose:

• Preparation over “flying by the seat of your pants?”
• Striving for continuous project improvement or just deliver the bare minimum to get by?
• Personally investing yourself in your project or “skate by?”
• Personal accountability for the results of your project or foist them onto someone else?

Is your project measuring up?


-- As always archives and originals of this blog, as well as the ability to comment can be found at Random Amateur.

Bucket List...

For no particular reason, I was musing this morning on my Bucket List. You know... that list of things you want to do in life, things that have significant personal meaning or satisfaction to you (and some only to you), before one punts thy bucket in thy maker's direction.

So what comprises my Bucket List? At last pass with a few updates, I see it as this:

1. Marry the woman of my dreams (planned for October 13, 2012).
2. See all three of my children graduate college, starting their own journeys into life (tentatively planned for around 2019, 2020, and 2023, give or take).
3. Hold a grandchild from each of my three children (but not anytime soon!).
4. Visit all 50 states in the U.S.A. (30 down, 20 to go).
5. Climb a snowy peak in a foreign land and gaze upon the world below me (I would accept a non-snowy peak as well, but I've done that twice, so it would have to be much taller).
6. Fly in the cockpit of a WWII combat aircraft.
7. Stand on every continent and sub-continent on this blue marble (by my count, I have done 3 out of 10, North America, India, and Europe).
8. Write a book, preferably fiction, that others read and recommend to their friends.
9. Be honored with a speaking engagement at my alma mater.
10. Travel into space (I'd accept suborbital as well... but really I'd like to earn an astronaut pin).
    

So not impossible, but looks like I have some work to do. I'd better get started...

--As always archives and originals of this blog, as well as the ability to comment can be found at Random Amateur.

Sharing the Victories... Analyzing the Defeats...

I believe that all victories should be shared... even celebrated... regardless of their size or importance. I wouldn't applaud any less loudly for a hand drawn work of art from my 6 or 8 year old than I did their first steps or I will when they graduate college (even if it may be ACME technical college and bartending school... which sounds like a great thing to invest in these days).

For victories, it should be the same in business. Share the victories... advertise... so that we all know what worked. Share your work product, making it available for everyone. Let everyone listen in on customer calls that are working well, in on project reviews that are effective. We can learn by observing something that works right. In a sense think of it as watching a teaching exercise before you turn to your own lab bench to try it yourself. I personally believe that we spend too much time ignoring what we do right with the excuse that we are concentrating all our time on the problems, since "they require our attention." If all you do is observe problems, you never see the complete picture.

But that is not to say we shouldn't spend time on our defeats. In that same same vein, analyze them. That is not to say seek blame and ridicule, but really sit down, like adults, talk about what worked, what didn't, what could have gone better, what could have been avoided, why we did it that way, could we have done it differently... the whole spectrum. And if everyone is too close to the problem to see the unbiased reality of it, invite in a third party. Not a leader, but someone who works in the trenches, to moderate the discussion. Give them the power to call someone on the carpet, even executives, when they think that person is leveraging bias into the discussion. And don't just look back on them... take a page from the victory plan... listen in on customer calls that are rough sailing, and on project reviews that are making no progress. Check out those deliverables that don't seem to be working well with this client (even it they worked at a dozen other places, there is a reason they are not working now).

In any discussion (victory or defeat) everyone brings value and insight to the discussion. On any complex endeavor, no one can really see the whole picture... you need an outside perspective. If you read any of the things I write or know me outside of work, you know I am a fan of the space program. Being a kid who grew up in Houston during the whole spin-up of the shuttle program, its hard not to be. In our example of analyzing our defeats, and who should be involved, check out the members of the Columbia Accident Investigation Board or the Rogers Commission that investigated the Challenger accident. On both panels I see members of NASA, military and former military, astronauts or former astronauts, researchers, engineers, and the occasional person how does not obviously jump out as a first choice to be there. My point is to bring together everyone who could contribute a perspective... I would say you never know what may come out of it, but actually we should know. We should expect that improvements will result from any analysis.

All in all anything you can learn from a victory or a defeat is valuable, but only if you apply it to the next project, task, or problem.

My personal favorite quote comes from Michael Holthouse, former President of Paranet, who I respect quite a bit. In general it went like this:

I want you to make mistakes... every day... if you are not making mistakes you are not pushing the envelope... you are not venturing into new territory... you are not learning... expanding your knowledge. But note... if you make a mistake once, its a learning experience. If you make the same mistake twice, its a learning disability and we will have words.

Let's say that you never wanted to have words with Mike!

--
As always archives and originals of this blog, as well as the ability to comment can be found at Random Amateur.

What is the Tech World Coming To?

I work day-in and day-out with technical people at all levels. I've been doing this for going on 22 years, and although its not a new trend, there is something that has finally annoyed me enough to write about it. Let's start with a little background...

Back in the day... you know the ones... when we used to program on clay tablets in cuneiform and when computers had 1K of memory... and you were lucky if it had status lights... I was a systems programmer and then a systems administrator. When we ran into something that didn't work or there wasn't a product out there that did what we needed it to do, well... we made it happen. We wrote scripts, code, fixed someone else's code or application, worked around the problem... hell... we rewired it if that is what it took to get it done.

I've written VAX/VMS Printer Symbionts (what they called printer drivers) in C, and extended one written in Fortran with C subroutines. I wrote my own TCP/IP sockets to push around print jobs between mainframes and mini-computers. I ran Linux kernels that had version numbers less than 1.0. I downloaded source code and compiled it... on platforms it didn't support.. and when that failed miserably, I would dig in and figure out why and fix it. My job was to get something done through my own ingenuity, skill, and hours of hard work.

But I'm afraid that, from all appearances, today's system administrators jobs see their role as being something completely different. From what I have observed they act as if their job description is to complain why it doesn't work and push the vendor, the consultant, or someone else (anyone else) to fix it for them.

• Why doesn't your year old application run on the latest Linux release that came out 3 weeks ago?

• Why don't you just explain to me this document rather than me taking the time to read it?

• I need something to do this thing that I really don't understand well myself, and I haven't really tried to fix it.
  
  
• I've not done any research, or even typed in a simple phrase into Google and pushed a button, but is there something out there that does this?
  
  
• I just don't have time to really work on this, since its hard and will take time to solve, but its important so can you do this for me?
  

Let me tell you how I view the world...

A programmer/developer/system administrator's job in life is to identify a problem, figure out a solution, and implement it - to deliver whatever service they are trying to deliver to their customers. If you use a vendor's product, then we vendors are very happy you chose us to help. If you haven't tried to solve it on your own, give it a try first (my 6 and 8 year old kids know this lesson...). If you can identify why your solution or our product doesn't work, or have some clue pointing in the right direction, we can certainly help you to fix it, since that is why people buy support contracts. Support is not there to do it for you. There is a whole other set of people for that, and they are expensive and charge by the hour, since they are doing your job for you. And whatever you are trying to tackle, its going to be hard... its going to take time... and you are going to have to think about it. If it is wasn't hard, it wouldn't be called "work"!

Your job is not a job. Its a trade... a craft... like blacksmithing, carpentry, portrait painting, or photography... you research your craft, grow your knowledge, and learn... every day... until you die. Not until you graduate college or in between moments reading comic strips and Slashdot on the web. If you can't find it in on the web, in a book, or in a manual, go figure it out... then write your own web page or book.... or develop your own product... since that is how the thing you were looking at got done in the first place.

So listen up you System Administrators:

Failure to try to solve it yourself first is poor trade-craft.

Any questions?

--
As always archives and originals of this blog, as well as the ability to comment can be found at Random Amateur.

Fish and Game

So back to the world of business and employment... this time with a little interactivity if there are any out there who want to comment.

So... there are many reasons why people work where they do. Big companies... small ones... public... private... more money... more satisfying... happier... busier... the list is endless. I learned a while back, from someone who was well paid to tell me this, that your job should be 70%/30%: 70% doing what you love to do... and 30% is that other stuff that just comes with the territory and we all have to put up with (time sheets, expense reports, paperwork, status reports, personnel issues, etc... whatever doesn't tickle your fancy).

But what's been stewing in my head lately is the theory of Fish and Game.

Fish...

Would you rather be a big fish in a small pond or a small fish in a big pond? I can't say yet I know if I necessarily prefer one over the other, but from my perspective I see some of the advantages of each. Not that each doesn't have its disadvantages, but work with me here... and lets see where this goes (yea... the mystery is revealed... I don't necessarily know the ending before I get there... its more fun that way).

So... being the big fish, you are the go to guy (or gal)... you are the one everybody depends on... you wear many hats... you swim all over the pond and cover a lot of territory... you are the big kahuna in the small company. Now small is relative. If you were at General Electric and went to work for a 2,000 person company... that would be small to you. Being the big fish has perks: leadership, privilege, deference from those around (or above) you... possibly even respect and admiration... short of them throwing flowers in your path as you walk and cheering you like Caesar... these may all be big fish things. I've been the big fish in the past... I can't say I am one now, even though my pond is small, but if you are the big fish it does have a few upsides.

But being the small fish in a big pond, one of many in a large organization, also has upsides. I've been there as well... to the tune of 50,000 person $5B revenue pond... which is goodly sized in my experience. Now you may or may not be less important than when you were a big fish, but there could be considerably more big fish around you... or just way more fish in general. You may still have the same perks and responsibilities, but the work load could be spread among more of your finned brethren. No one is going to argue that a piranha isn't a fearsome little fish. I certainly wouldn't want one in my bath tub. But (their reputation being anecdotal or not) I wouldn't want to encounter a whole school of them. And being in the big pond, your company support system could be considerably more mature. Not to mention you could have a more defined role that goes deeper into a narrower focus area (it not being your job to swim around the whole pond).

Now where does this get us... well... Game...

One thing I very much prefer, almost with any doubt, is I like being surrounded by high performers. Experts... people smarter than me... those I can learn from (a nod to the Texas A&M crowd in Dallas... who without a doubt are some of the leaders in the VoIP industry... and big brains all... I feel like a intellectual Tiny Tim in their presence).

Now... I don't care if those other big fish are paid more than me. Over my years as a manager I've had countless people work for me that made heaps more than I did, and I was good with that. I needed them and their skills. Why? These other high performers have "got game" and I believe that surrounding myself with them will make me better at what I do. A rising tide lifts all boats... so to speak. If I do something, and someone takes it and makes it better, then it gives me a higher platform from which to leap to my next achievement (and the company benefits all along the way). Those fish stand on my shoulders... I then stand on theirs... rinse and repeat until we are at a height that we could not have achieved individually. In my book, working in this way with people who have got game is the ultimate form of teamwork.

Now, no matter your size of fish... if you are surrounded by people with game, you all can achieve more. If however you are one of the few with game or you feel like you are constantly pulling up those around you who seem to be lacking a certain amount of game (or any)... well... I am of the belief that you will not achieve near as much. And that means your company won't either. Both of which are very frustrating, both personally and professionally.

I've seen more than one company presentation that basically say that their goal is to have all high performers and anyone not capable of demonstrating achievement at that level needs to find somewhere else to be. I know that sounds harsh... but just because someone is not able to demonstrate achievement in Company A doesn't mean that they are not a perfect fit for Company B. They are not bad people... they are just in the wrong place at the wrong time. If they were at the same company but ten years later, it may be perfect for what they can do... and the same goes for not being there earlier. High performing, no-holds-barred entrepreneurs may not work out well at a large, well established company... and a 9-to-5, by-the-book, non-innovator may not fit in well at a fast paced start-up.

So... Fish and Game...

I'm happy being any sized fish in any sized pond... but I am convinced that if I am not surrounded by fish with major game, all is not right with the universe.

--
As always archives and originals of this blog, as well as the ability to comment can be found at Random Amateur.