Archive for the ‘- Darrell G. Stiffler’ Category

PMI vs. ITIL: How Are They Different?

Posted on February 6th, 2012 in - Darrell G. Stiffler, Certification, IT, Project Management | No Comments »

By Darrell G. Stiffler, PMP

Note: This is part 2 of a 3-part series on PMI vs. ITIL. Read part 1 PMI vs. ITIL:  How Are They Different Part 1 here.

This part of the comparison is about Information Technology Infrastructure Library (ITIL). I am told that it is pronounced “idle”, like in “the idle rich” or “my car idles badly.” I personally do not like that pronunciation.  It conjures up a vision of people standing around waiting for the go home whistle to sound (does any company do that anymore?).  I and some other authors I’ve spoken with pronounce it like “I tell.” That makes more visual sense to me. I visualize some leader telling the troops what to do and how to do it. The leaders telling the troops what to do and how to do it is exactly what ITIL is all about. ITIL is a framework of Information Technology Operational Organization Structure.

ITIL is a framework of best practices for quality IT Services Management. IT Service Management is defined as the delivery and support of IT services to meet the business needs of an organization. The recommendations of ITIL were developed in the late 1980s (around the time PMI’s PMBOK® Guide was published). ITIL origination was in the United Kingdom Central Computer and Telecommunications Agency (CCTA) which later merged into the Office of Government Commerce (OGC). ITIL has been adopted and accepted as a global standard for IT service management since the mid 1990s. There were predictions in the late ‘90s that ITIL would sweep the IT industry and by 2005 it would be the core practice of any large organization’s IT world; however, when those predictions were made they didn’t anticipate the crash of 2001 and subsequent bad economics for the next 10 years. Had the economy not crashed, we would all know more about ITIL. The adoption of ITL is expensive in both time and money.

I suspect the seeds of ITIL began when portfolio managers began to complain that the IT department was getting too much of the budget and they weren’t getting the value that they wanted. The structure of ITIL is to set up the IT department as an independent business. One of the first projects, which should be treated as a project with all the PMI rigors, is to publish a Services Catalog. A list of reports, online applications, web sites, etc., which the IT department offers to the company and sometimes even outsiders of the company. The purpose is a statement to the portfolio managers, “if you don’t like our prices, check the competition and you will see that we are competitive.” Of course not all companies, because of proprietary and confidential information, have the luxury to go to a competitor; however, if rates are published there can be some comparison shopping. This can be a real advantage to a portfolio manager if the IT is not proprietary or confidential. It will allow the portfolio managers to consider outsourcing to vendors that can take advantage of shared resources with other companies. This can have a very positive effect on the company’s bottom line.

The heart and soul of ITIL is the service desk. In the good old days we called it help desk, but someone decided to jazz it up and call it a service desk because it really does do more than just take “I broke it” calls. The service desk is a Single Point of Contact for the whole IT organization, whether you are a programmer, network specialist, hardware repair or install specialist, manager, change control specialist, configuration management person or whatever. There are several sophisticated software packages and a heart stopping price to help you manage the service desk.

There were two ITIL versions – v2 and v3. V3 is the latest path and v2 is going away or gone.  ITIL has two paths to certification. Both paths begin with the”v3 Foundations” class. The two paths are Service Support and Service Capability.  Both end with the ITIL Expert and then ITIL Master. The Service Lifecycle is a more technical path where Service Capability is more of a management path. Both paths include multiple courses. As you take and pass the exam course you are awarded points, eventually allowing you to sit for the Expert and then Masters Certification. As with the PMP® certification you must document your experience, which is necessary for the higher certification. Since this blog is a high level understanding, I won’t go into the listing of classes.

With the similarities in the use of process by both PMI and ITIL one would think they would be joined at the hip. Well, the challenge is that ITIL has its own project management approach called PRojects IN Controlled Environments (PRINCE) with the latest version called PRINCE2. The method PRINCE2 is in the public domain, offering non-proprietary best practice guidance on project management. PRINCE2 is a registered trademark of OGC. There are two PRINCE2 qualification levels: PRINCE2 Foundation and PRINCE2 Practitioner. PRINCE2 Foundation level is for those with a requirement to learn the basics and terminology of PRINCE2.

ITIL is a challenge to implement. The scuttlebutt is that you have to try to implement ITIL three times before you might succeed. It takes a great deal of commitment by the organization in time and dollars. There is essentially an organizational chart of roles and responsibilities that must be filled.  These roles and responsibilities are not easy to fill and generally take experienced and expensive employee types; however, with that said, once implemented and maintained well, the organization can be very effective. This gets a little confusing.   For more information the website www.itil.co.uk has been replaced by the Best Management Practice website and the official ITIL website managed by the Best Management Practice partnership.

The third part of my blog will be a summary.

Originally published on Idea.com.

PMI vs. ITIL: How Are They Different?

Posted on December 20th, 2011 in - Darrell G. Stiffler, IT, Project Management | No Comments »

By Darrell G. Stiffler, PMP

Note: This is part 1 of a 3-part series on PMI vs. ITIL.

The terms Project Management Institute® (PMI) and Information Technology Infrastructure Library ® (ITIL) are tossed about with the assumption that everyone has the knowledge and experienced to know what these two organizations are all about.  That would be a false assumption.

Based on an email I received asking for the basic difference and similarities between the two, I intend to do a high level explanation, with enough information to get you thru a basic conversation.  This will be a many part blog, as to hold you in suspense and make you eager for the next publication J (Did I mention you had to have a good sense of humor to be a good project manager).

PMI and ITIL are mutually exclusive, meaning you can have a performing organization using ITIL organizational structure without using PMI methodology OR you can have a performing organization using the PMI methodology without using the ITIL organizational structure. There is real synergy when both are implemented, endorsed, and supported by senior management. A very important point must be made. If Senior Management does not fully support the PMI approach and the ITIL structure, they both have a low probability of succeeding.

Let’s start off discussing the PMI. The PMI was established in 1969. It was originally formed by a small southern university to put structure to the construction industry. In 1981 the PMI Board of Directors authorized the development of the “A Guide to the Project Management Body of Knowledge (PMBOK)”. Subsequently the PMI and the PMBOK have become the de facto standards in project management. The PMI is all about a structured process approach to project management. I hear the word “project” tossed around very loosely in the business world. It is often misused, almost as often as the term “Critical Path”, but that is another blog. For an event to become a project it must possess three characteristics.

1)      It is “Temporary”; it must have a specific start and end date.

2)      It must, at the end of the project, produce a unique product, service, or results.

3)      The event must use “progressive elaboration”.

Those are the key requirements that make an event a project. If it doesn’t meet those standards it is an “Operational” event. Projects are a subset of Operations. ITIL is all about operational organization structure. The PMI with the PMBOK gives a project structure, organization and suggested process.  A process is “A series of actions or task performed to achieve pre-described output or results”. Process is one of the binding similarities between PMI and ITIL. The PMBOK is a kind-of a road map regarding how to manage a project. The basis for the process used in project management are the five process groups:

  1. Initiating
  2. Planning
  3. Execution
  4. Control & Monitoring
  5. Closure.

And the nine knowledge areas:

  1. Integration
  2. Scope
  3. Time
  4. Cost
  5. Quality
  6. Human Resources
  7. Communication
  8. Risk
  9. Procurement

By combining these process groups and areas of knowledge there are 42 processes that are used in the PMI approach to project management.

The PMI offers a variety of certifications. The most popular and most recognized is the Project Management Professional (PMP) certification.   There are in excess of 400,000 PMP’s in the world. This is a dynamic number that increases monthly. The PMP certification requires documentable years of experience in project management and must be able to pass the certification test. Most aspiring candidates assume that by reading and studying the PMBOK they can pass the test. One big caution, note that the title states that it is a “Guide”. This is a very important subtlety in the title. What the PMI is alluding to is that not all you need to know to pass the PMP examination is in the PMBOK.  You must have more knowledge than what is in the PMBOK.

After one reads or starts reading the PMBOK, the usual reaction is “this is all common sense, however if we did all these steps and filled out all of these forms, we’d be over budget and not have much accomplished”. I usually say at this point, this is about being a manager and using common sense for an approach.  You may not need all the forms and process to do your project, however don’t disregard some of the major steps. Planning is the key to success, whether you are using the PMI approach to project management or ITIL in your organization structure.

In summary, PMI and ITIL are both about approach, structure, and process. PMI is about “Projects” and ITIL is about “Operational Organization structure”. If you wish more information on PMI and PMP the official web site is http://www.pmi.org/. The next blog will be more about ITIL.

Originally published on Idea.com.

A Different Approach to Practice Testing for PMP Certification

Posted on January 17th, 2011 in - Darrell G. Stiffler, Learning, Project Management | 1 Comment »

by Darrell G. Stiffler, PMP

If you are preparing to take the Project Management Professional (PMP) examination, I have an idea I would like to share.

You have probably been told the best way to prepare for the exam is to take as many practice exams as possible. I could not agree more. Because of the nature of the PMP examine, the wording of the questions can be very confusing. The Project Management Institute (PMI) also includes wordy questions; correct answers, but to another question; impossible questions, etc. The exam is a challenge even if you know all the material. It is as if you have to know the material AND understand how to read the questions and decipher the code.

I have taught PMP Exam preparation courses for some years now. I recently had a student who had an approach to taking the test that I thought was very creative. It could be that this idea has been around for some time and I have never heard of it. If so, I guess I’m the last one to hear about it, part of the 10% that never gets the word and when they do hear about it, they feel like they need a dunce hat. If this tip is not widely known and I come across as a genius, I’ll never tell that Bryan in my Washington, DC class, came up with the idea.

Here is the deal: when I take a multiple choice test, I do a certain amount of cogitation and guessing. When I’m done with the test and look over the answers, if I get the question correct, I breeze quickly past that question and focus on the questions that I answered incorrectly. Well folks, I’m here to tell you that not all the questions I got correct were because I knew the correct answers. Yes, I guessed. However, because I got the question correct on the practice test, I never reviewed the material that the question was referring to. We both know that this is a recepe for disaster later on. Therefore, the approach I suggest to the small minority of those who guess on questions is as follows. Take paper and write down the number of questions that you have on the test. At the top of the paper, write this scale:

                        Confidence Level 
  1 = Don’t have a clue what the answers is.
  2 = Kind-of think I might have heard the terms before somewhere.
  3 = Know most of the words and definitions of the terms.
  4 = Pretty sure I know what they are asking about and think I know the answer.
  5 = Nailed that one, piece of cake, I wish they were all this easy.

As you answer the questions and write down the alpha character that is associated with the answer you have chosen, also write down the confidence level number associated with the above description.

As you go back through and grade your answers you will now be reminded if you guessed or knew the answer to the question. If you got the answer correct but guessed at the answer, you will know to brush up on the subject. Additionally, you could add up the values of all the questions and divide by the number of questions and get a good idea how confident you were taking the test.

Let me hear from you. If you try this approach and it works for you, let me know, it will make me feel good and feel like I contributed to my profession, which by-the-way is part of the Code of Ethics. If you have already heard of this approach, let me know and I’ll not mention it again and embarrass myself.

Good Luck!

Sometimes They Just Don’t Know. What Really Motivates?

Posted on October 13th, 2010 in - Darrell G. Stiffler, Leadership | 1 Comment »

by Darrell Glen Stiffler, PMP

Victor Vroom’s Expectancy theory has been around about 46 years now and is consider one of staples of Motivational Theory. The subject pops up a lot when studying project management. Although Vroom’s Expectancy theory is not mentioned in the Project Management Body of Knowledge (PMBOK® Guide), it is rumored to be asked about on the Project Management Professional (PMP) certification test. 

The theory is quite simple and deals with motivation and management. According to Wikipedia, “Vroom’s theory assumes that behavior results from conscience choices among alternatives whose purpose it is to maximize pleasure and minimize pain. Vroom suggested that the relationship between people’s behavior at work and their goals was not as simple as was first imagined by other scientist. Vroom realized that an employee’s performance is based on individual’s factors such as personality, skills, knowledge, experience and abilities.” 

It has been my observation over the years that, some Individual Contributors (ICs) just don’t know what motivates them. Oh, sure you can talk money, title, time off, more discretionary choices regarding work, etc. Most ICs will assure you that one of the standard “motivations” listed will do the trick for them. That is until you try to motivate them with one of the “motivators”. After agreeing with the IC which one of the “motivators” is the key, the IC still does not perform as agreed. They will say that they changed their mind and what they really wanted was something different. When that happens, the relationship between manager and IC goes south.

What can be done to prevent this chain of events? My approach has been not to suggest any possible motivators. Let the IC come up with a written list of top five motivators for them. It has always surprised me how many people cannot come up with three. Once the motivators have been established, be sure to set roles, responsibilities, expectations and, most importantly, metrics. Be very specific as to what the reward will be if they perform as expected. “I’ll give you some time off” is not specific enough and will create a problem later on. Never give a range of rewards, for example. “You do a good job and I’ll make sure you get a 4% to 6% raise next anniversary”. That statement is a going to cause problems. First, “good job” is not specific enough because of lack of metrics. Secondly, The IC just heard the manager say they would get a 6% increase on their anniversary, and the manager thought he said that the IC would get a 4% increase on the anniversary.

I think Victor Vroom has a good idea, but it, like many things in project management, is situational. If you have ICs that don’t know what their motivations are, be patient with them. If you both keep on trying, you’ll find something someday.

What are your top 5 motivators?

Forward Momentum Logo
Forward Momentum Logo