Archive for the ‘- Darrell G. Stiffler’ Category

SME Creep

Posted on April 23rd, 2012 in - Darrell G. Stiffler, Communication, Constraints, Leadership, Resources | No Comments »

By Darrell G. Stiffler, PMP

Subject matter experts (SMEs) are generally a very valuable asset to a project manager (PM). However, as a PM, you must be prudent in how much authority and control is given to or taken by a SME. Additionally, you must be aware that a SME can slowly erode your authority, even without a direct confrontation.  When a PM begins to have the authority slowly taken away by a SME, it is called “SME creep.”

I’ve been there. You have been assigned a project to manage and you don’t have experience in the area that you’re about to manage; a project that could make or break your career.  As Frank, the boss, gives you your assignment, you’re wondering if he is speaking English. He is throwing acronyms and technical jargon at you so fast that your head is swimming. However, as if to wish you lots of luck, he reassures you by saying, “Now I am asking Bob, our SME in this area, to give you support and be there to help, if you should need him. Of course, he has his full time job, and so he may be a little slow in responding to you.”

Just great. You’re responsible for the project – assuming you can untangle the jargon into plain English – and someone else has all the knowledge. Your team is looking to you for guidance and direction. Bob is working a 50 hour work week, just trying to keep his head above water. You want to set up a meeting with Bob.

You send Bob an email and say, “What is a good time for us to meet to talk about this project?” You’re trying to be understanding and cooperative. That is a nice consideration. However, you are sending the wrong message to start the project. What you are subliminally saying is, “I recognize your time is more valuable than mine, so I will let you take the lead.”

Some may disagree with my interpretation of this situation, and that is OK. I realize there are SMEs out there that would not take it that way and would be thankful that you where being considerate. Then there are others that would, perhaps subconsciously, take it just the way I presented it. Bob sends you back an email stating that he will be able to squeeze you in tomorrow at 5:30 PM, knowing that the standard working hours are 8:00 AM to 5:00 PM at his office. You realize that you are a salaried “professional” and sometimes (most of the time) you have to work a “professional day” (which means no overtime), so you agree. Strike two for you. By letting Bob set the location, you once again are giving him the upper hand and implying that you must go to Bob instead of him coming to you.

You show up at his office two minutes early. He is on the phone talking “technical speak.” He motions for you to come in. He raises up one finger, indicating that he will just be a minute. So you sit there looking around the room at all the technical posters and books that have multi-syllable words in the title. You glance at your watch and that one finger minute has turned into ten minutes and Bob’s conversation shows no sign of slowing down.

Strike three. Bob obviously does not respect your time or he would have ended the conversation when you walked into the room. You haven’t spoken a word about the project and you have already lost control.

It just goes downhill from here. After you have waited for 15 minutes, Bob finally gets off the call and apologizes profusely. Don’t let that fool you. You begin the conversation by giving him a little background on yourself. He stops you after about two minutes into your opening and says, “Frank,” (your boss), “tells me you’re a little ‘weak on experience’ on this project.” He clears his throat. “Don’t worry, I know enough about this project for both of us.” This is another bad sign. He does not want to listen to you because he thinks he knows everything, and the boss has confided in him that you are “weak” on the subject.

I could go on with this scenario, but that would be just more to read and you wouldn’t get much out it except more ways of identifying that you were in trouble.

Consider this approach: Interrupt Bob and say that you are glad he is on the team. This is very subtle way of telling him he is a team member, not the team leader. Secondly, say, “This meeting has run over the time I had allotted. Do this for me,” (in a friendly tone), “put together a list of the deliverables. Do you know how to do a WBS? After drafting a WBS, would you put together resource requirements with roles and responsibilities, and then a time estimate, based upon your suggested resource requirements, and show me a time line and the critical path? You’re probably the best choice to do this since you are so familiar with the project requirements.”

Wow, what did you just do?! By him making the statement that he knew enough for the both of you about the project, he just said, “I am the only person that knows what to do.” So you loaded him up with enough work to “choke a horse”!

If he is all “techie,” he won’t know how to do those tasks, so he will have to refer back to you for guidance and it will be clear that you have taken back the leadership role. If he does know how to do all those assignments, that’s great; you can grade his papers. In either case, you are clearly the one in charge. Be fair with your evaluation of his work, but make it obvious that you are supervising him, not just taking everything he does as gospel. This will reinforce your authority. If you can, get together a committee that you obviously run and put his work in front of a committee, reinforcing the point that he is part of a team.

As with most everything in project management, this is a “situational” scenario. You must adapt to the personally of the SME and the operational process assets of your organization. I hope you are never put in this situation. However, if you are, you might consider this approach.

Good Luck.

 

PMI vs. ITIL: How Are They Different?

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

By Darrell G. Stiffler, PMP

Note: This is part 2 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 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, Certification, Learning, Lessons Learned, Project Management | No Comments »

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!

Forward Momentum Logo
Forward Momentum Logo