Weekly Inspirational Poem

This week’s inspiration comes in the form of poetic writing rather than a literal poem. Taken as an excerpt from Orisen Swett Marden’s book, "Selling Things," this quote says much in just a few words:

Everything depends upon the attitude of mind with which you approach a difficulty. If you are cowed before you begin, if you start out with an admission of weakness, a tacit acknowledgement of your inability to meet the emergency that confronts you, you are foredoomed to failure. Your whole attitude lacks the magnetism that attracts success.

-Orisen Swett Marden, Selling Things, 1916

Weekly Inspirational Poem

This week’s poem, by Helen Steiner Rice, reminds us that there is always the chance to start anew as long as we keep on breathing.

How often we wish for another chance
 to make a fresh beginning.
A chance to blot out our mistakes
 and change failure into winning.

It does not take a new day
 to make a brand new start,
It only takes a deep desire
 to try with all our heart.

To live a little better
 and to always be forgiving
And to add a little sunshine
 to the world in which we’re living.

So never give up in despair
 and think that you are through,
For there’s always a tomorrow
 and the hope of starting new.

What is ITIL?

When I teach project management and operations classes, I am frequently asked this question: What is ITIL? There seems to be a lot of buzz around this methodology and this buzz exists for good reason. ITIL is like Open Source for technology management.

ITIL stands for Information Technology Infrastructure Library (ITIL). The ITIL is technically a documented set of best practices, but the term is often used to reference the certifications based on the ITIL. When I say that ITIL is like Open Source for technology management, I do not mean that the ITIL books are free. They are, of course, floating around on the Internet in pirated form, but the books are copyrighted and ITIL is a trademark.

My statement about Open Source, simply refers to the fact that ITIL is based in universal best practices. These best practices may not be "best" for every organization, but they are generally accepted in the industry. When the library is updated, many people through the IT and business sectors are involved in order to provide a true set of best practices as opposed to the recommendations of just a few IT managers or CIOs.

The best way to think of ITIL is as a foundation on which you can build the actual service management environment that you need for your organization. The LEAN IT operations model that we developed at The Systems Education Company certainly includes many recommendations that are also included in ITIL; however, because we are more focused on implementing technology as efficiently and effectively as possible, we do not encourage blind exhaustive implementation of ITIL best practices. You will want to ensure that the practices you implement do not cost more than they gain.

This thinking is not unique to ITIL. For example, the Project Management Institute’s project management body of knowledge (PMBOK) should also not be blindly implemented as a strict methodology in and of itself. Instead, we can use it as a foundation on which we build solid project management systems.

So, what is ITIL? It is a fabulous place to start as you build a lean and mean IT operation.

Weekly Inspirational Poem

This weeks’ poem speaks to the reality that it is better to focus on what we can do rather than what we can’t.

Don’t hunt after trouble, but look for success
You’ll find what you look for, don’t look for distress;
If you see your shadow, remember, I pray,
That the sun is still shining, but You’re in the way;

Don’t grumble, don’t bluster, don’t dream and don’t shirk,
Don’t think of your worries, but think of your work.
The worries will vanish, the work will be done,
No man sees his shadow who faces the sun.

-Source Unknown

The Smell of Smoke

This past Tuesday morning at about 1:15 AM I rose out of bed to the smell of smoke. As I walked down the stairs, the smell grew stronger and as soon as I turned on the lights I noticed the source. Seeping out around the location where the stove pipe enters the chimney was a continuous flow of smoke. A raging chimney fire was under way.

The following picture shows the damage from the inside (the outside view is a bit more discouraging so I don’t want to post it here where I may see it from time to time). As you can see, the major damage area was confined to the wall behind the stove; but why? If you know me, you know that I’m always trying to learn lessons out of life. In this post, I want to share three lessons of which this fire reminded me.

Chimney Fire

  1. Install smoke detectors. We have smoke detectors in our house. They didn’t help in this situation because my built-in detector (my nose) worked faster than they did and we were able to call the fire department before the fire set them off; however, this does not diminish their value as I cannot always rely on my senses alone. The smoke detectors are analogous to the key performance indicators (KPIs) that we watch in our IT projects. A good project management system should allow you to configure thresholds for the KPIs associated with your projects. This way you won’t have to watch (or smell?) your project every minute of the day.
  2. Listen to your nose. My nose sensed something out of the ordinary. Because I listened to it, the worst of the fire damage was contained to one room in the house. Had I ignored it, things would have been much worse. Your physical senses are analogous to the instinct or intuition that you build over time. This is a key difference between experts and professionals. The expert has developed her instincts with more than 10,000 hours of practice. Listen to your instinct before your project gets out of control.
  3. Get out of the house. The first thing we (my beautiful wife and I) did was get the kids out of the house. Sometimes as a project manager, you need to know when to bail. It’s part of effective project management. Some argue that successful project planning will prevent project cancellation. I suggest that project cancellation is part of effective project management in a real and dynamic environment. Certainly, we want more successes than failures; but without failures, one has to ask if enough risks are taken.


Maybe these lessons will help you on your next project. I know they are fresh in my mind. Now that the dust has settled (literally, all over my house) I can evaluate the damage and make reparations; however, I know the damage is less than it could have been because we installed smoke detectors, listened to our noses and got out of the house.

Project Management Methodology: Do you have one?

A methodology of project management or a project management methodology can simply be defined as the method by which you manage a project. Everyone uses a project management methodology, it’s just that many project managers change their methodology on each project. Here’s the question I’d like to answer: What’s the benefit of a standardized project management methodology in the first place?

I would suggest that a standardized methodology provides the following four primary benefits:

  • Collective knowledge
  • Greater predictability
  • Capability maturity
  • Reduced stress


Now, I know that last one is hard to swallow since many people think of a project management methodology as a source of added stress via the requirement of added documentation; however, I would suggest that a well-documented methodology reduces stress because you never have to ask, "What do I do next?" You have inputs, processes and outputs. The methodology of project management should indicate the source of the inputs. Next, it should state what you will do with those inputs (the processes). Finally, it will provide you with forms or templates that you fill out as a result of the processes (outputs).

With the last benefit covered first, let’s go back to the first listed benefit: collective knowledge. There are many things in life that we trust. For example, we trust that it really is safer to wear our seatbelts than to drive without them (at least I haven’t done actual research myself). This is collective knowledge. A documented project management methodology provides the same benefits. If you use a template that was created out of experience and education, you will reap the benefits of using that template whether you know it or not. This, in a nutshell, is the benefit of collective knowledge.

The second stated benefit was greater predictability. Since you are using established inputs, processes and outputs, you can predict with greater certainty how your project will go based on how it starts. Additionally, you can look at the project at any point in the lifecycle and make estimates as to the outcome using established and mature processes.

That last statement leads me to the third and final benefit (since I covered stress reduction first): capability maturity. A solid methodology of project management will be maturable. It will include a lessons learned process at the end of the project that may be used to mature or improve the methodology. This increases the "capability" of the project management methodology to meet the needs of your organization.

My suggestion is that you do not start from scratch. You can use PMI best practices as a starting point or another model like The Systems Education Company’s Method 4D methodology. However, no matter the starting point, you will reap these benefits and more if you begin to use a methodology and then mature that methodology over time.

Waste in Information Technology

I was reading a post at Curious Cat that discusses IT waste today and it started the gears turning down an old familiar path. I remember, in the last recession, how people were talking about the need to cut costs in IT investments. I also remember that many bad decisions were made because the complex interdependencies among IT systems and processes were not considered. How do you detect waste while avoiding the gap problem?

The gap problem is my way of concisely saying that many apparent wastes are actually needed bridges between systems or processes. For example, you may notice that a database is being maintained and that no users ever access that database. Furthermore, you notice that the database has not been accessed in the past three months at all. Your logs do not go back any farther. The database is part of a system that was developed three years ago and no remaining employees were involved in its creation. This seems like the perfect candidate for waste reduction.

Since the database seems to be an unused maintenance waste, you decide to delete the database and all associated logs. Three months later, you receive a phone call from someone in Engineering complaining that their data archival procedure is erroring out. The error message says something about a missing database. Get the picture?

This is a very simple example of what I call the gap problem. Many of our systems and processes bridge the gap between other systems and processes. These gap solutions may appear to be waste when they are actually necessities. So, how do you deal with the gap problem? I would suggest the following steps:

  1. Perform detailed process mapping for all Information Systems.
  2. Look from the top down instead of simply from start to finish.
  3. Cut waste only when the entire complex of interdependencies is understood.


Of course, a small blog post like this cannot go into all the details, but you can begin to see important realities. I am a big believer in process mapping (when it is done right) and I believe it can help eliminate true waste while preventing the gap problem. When I say that we should look from the top down instead of from start to finish, I mean that we should consider not only the path of a single process but the intersections that a process has with other processes and systems.

This is a starting point and, as I said in a recent post, we need to answer the question: Other than human capital, what can you cut while maintaining current service levels? Yes, it is time once again to trim the fat.

What is Virtualization?

VMware is adamant about their definition of virtualization. In fact, I’ve been told that you could do poorly on their VCP-310 exam if you think that virtualization and emulation are the same thing. Are they right? Is there a difference betwen emulation and virtualization? Is virtualization better? I’ll give my two cents worth in this post.

Personally, I use the terms virtualize and emulate interchangeably. I do not see a difference – at least not a difference that favors virtualization as if it were better than emulation. In fact, I would suggest that – if anything – emulation does more than virtualization.

The "emulation scene" is a varied subculture on the Internet that provides software-based emulation of historic and modern devices. For example, you can download Commodore 64 emulators and Apple II emulators. These applications emulate, or virtualize, the hardware of the specified devices. No one would say that a Commodore 64 emulator does not perform emulation and, likewise, no one would say that the emulators do not result in a virtual Commodore 64 (My PC doesn’t literally become a Commodore 64 when I run the software does it? That would be very cool!).

However, the brilliant folks at VMware (and I do mean it as their technology is exceptional in the industry) seem to have a problem with the word emulation. I contend that they are wrong and are making an unneeded distinction that removes a simple analogy from the educational process. When you show someone a Commodore 64 emulator and then say, "We can emulate a modern computer too. That’s what virtualization does." they get it. They understand virtualization instantly and they understand it right.

My point is very well illustrated in Elias N. Khnaser’s book "VCP VMware Certified Professional". He says:

A common mistake that people not familiar with virtualization make is that they think virtualization is similar to emulation or simulation. The fact of the matter is virtualization is neither emulation or simulation, because with virtualization you install the actual operating system on virtual hardware. You go through the same steps, and the operating system itself does not know that it is being installed on virtualized hardware. Furthermore, virtualization requires no custom development or programming of any sort, whereas simulation and emulation do.

Apart from the interesting question that now haunts me – does the operating system know when I am installing it on physical hardware – there are some real problems with the thinking that lead to this paragraph. Before I point the errors out, however, let me say that this book is a great overview of the VMware product line. I find no technical fault at all in the book and think it is a five star book all the way.

Problem one: "with virtualization you install the actual operating system on virtual hardware."

Emulators actually include the operating system when they emulate older computers because those computers came with the operating system in ROM. The Commodore 64, TRS-80, Apple II and more, all include the OS in the hardware. Therefore, one could argue that the emulators that virtualize these computers are doing more than modern virtualization, if you do not consider the other hardware that is emulated (oops, I mean virtualized) by modern PC emulators (I mean virtualizers).

Problem two: "the operating system itself does not know that it is being installed on virtualized hardware."

When you run a Commodore 64 game on an emulator, that game doesn’t know it’s running on virtualized hardware and emulated software. The game thinks it is talking to the Sound Interface Device (SID) chip, but it’s not. The chip is virtualized.

Problem three: "virtualization requires no custom development or programming of any sort, whereas simulation and emulation do"

I take no issue with concerns over the word simulation as it is different than emulation or virtualization – you simulate scenarios and you emulate things. However, to suggest that emulation requires custom development is simply untrue. You can run an old Apple II game on an Apple II emulator without writing a single line of code. There is no difference.

To be clear, these are the only arguments mentioned in the book. They are indeed stated with force, but they are not themselves forceful as they paint a picture of emulation that is at best foggy and at worst simply misguided. Why does VMware (and even Microsoft to some extent) dislike the term emulation? Maybe because free applications that people developed in their basements have been doing it for way more than a decade.

In the end, there can be no question. A Commodore 64 emulator is a virtualization solution. The same is true for all software programs that emulate a piece of hardware. This includes calculators, gaming consoles and old computers. The legality of these programs may be another question, but that they are soundly in the virtualization category is not at all questionable to me.

Weekly Inspirational Poem

This week’s poem comes from the book, "The Secret of Achievement" written by Orison Swett Marden and published in 1898. The poem reminded me of a Sunday School lesson I once taught. While teaching a group of teens how to look on the brighter side of life, one young man asked, "If there’s a way to fund something good in every situation, try this. What if I fall and slip on the ice outside of the church building today?" I thought for a moment and then replied, "Then the elder church members will know that the spot is slippery." This answer may not have been the answer he desired, but it is so very true of life.

If nothing else, maybe someone else can learn from our mistakes.

Fail – yet rejoice; because no less
The failure which makes thy distress
May teach another full success.

It may be that, in some great need,
Thy life’s poor fragments are decreed
To help build up a lofty deed.

-A. A. Procter

What to Communicate Now

I frequently tell seminar attendees that the most important skills a technology professional can develop are communication skills. I’ve been saying this since 1997 and I can’t see a reason to change my opinion now.

In fact, I would suggest that the current economic conditions make communications more important than ever. If you are the IT manager or the IT director for your organization, I would encourage you to communicate the following information to your manager or director in the next two weeks – regardless of the normal procedures:

  • What does your current budget look like and how can you help save the organization money in the next 12 months?
  • Other than human capital, what can you cut while maintaining current service levels?
  • What planned expenditures can be delayed and how will you deal with the productivity and functional limits the delay will cause?
  • What are your top three ideas for running IT more efficiently?


Sharing this information will show that you’re thinking about the organization and you want to help everyone weather the storm. It not only builds good will; it is just plain good sense in times like these.