A memorable Rumsfeld quote: Project Management-speak
More than ever, the political scene lately has generated some memorable and oft-repeated phrases. No, I’m not going to discuss the meaning of ‘is’ or pick on Greenspan’s ‘irrational exuberance’ or one of President Bush’s many tongue twisters. Instead, I want to discuss a quote by Donald Rumsfeld.
Donald Rumsfeld, former Secretary of Defense, in answering a question about weapons of mass destruction in 2002, patiently explained:
“As we know, there are known knowns. There are things we know we know. We also know there are known unknowns. That is to say, we know there are some things we do not know. But there are also unknown unknowns, the ones we don’t know we don’t know.”
While this quote sounds extremely confusing, this statement doesn’t need to be explained to many of us project managers, especially those among us who have attended formal PM training and/or passed the PMP® exam. Those of us who practice sound risk management and budgeting know exactly what he is talking about.
We learn in training that known unknowns are those items that we identify on our projects which may occur. We often call these risk events or risk items. They are known because we identify them, they are unknown because we do not know if they will occur or not. For those, we apply a contingency or buffer. The unknown unknowns are those items which we don’t identify up front as risk items, whether because of poor planning or because we could not have anticipated these events. These are called unknown unknowns because they are not identified (unknown) and we don’t know whether they will occur or not (unknowns). Unknown unknowns are those items that catch us completely by surprise, and management reserve covers those, in terms of additional money or time. The unknown unknowns are a much smaller percentage of risk items than most people think, because most items should be able to be identified. This is part of good risk management and understanding your budget.
This begs the question. Was former Secretary of Defense Donald Rumsfeld a Project Manager? Stay tuned to Part 2 of this thread to explore this question.
Vicki Wrona, PMP®is the founder and President of Forward Momentum, LLC, an 8(a) consulting and training company found at www.forwardmomentum.net. She has been managing projects and mentoring project managers for the past 20 years in both the private and public sectors. She is an instructor for Global Knowledge and developed GK’s PMP® Exam Prep Boot Camp, part of the program that won PMI’s ® Professional Development Product of the Year Award in 2007. She has trained over 3,300 professionals, including over 1,600 on the PMP® exam. Currently, she is serving on PMI’s® PMBOK® Guide 4th edition creation and review team.
Donald Rumsfeld: Lessons in Project Management
In the first part of this blog, I explored a quote by former Secretary of Defense Donald Rumsfeld that sounded extremely confusing, but one which makes sense to project managers who practice sound risk management and budgeting. This installment will discuss whether Donald Rumsfeld was a project manager in his role as Secretary of Defense.
Was Donald Rumsfeld a project manager? Much of his work involved projects or temporary, unique items which should be managed like projects. Did he follow proper PM principles?
Let’s take the Iraq initiative. I don’t want to get into philosophical debate on the war in Iraq, but instead step back and take a look at it from a project management perspective. The initial military activities in Iraq seemed (from my outside and admittedly limited perspective) fairly well thought out, and the operation itself was planned and implemented. From a project perspective, so far, so good. But what was not planned was the transition from project to operation, or in other words, the plan after the initial military operation accomplishes its goals. It does not seem that there was a plan to manage the transition from one government to the next and then hand off the end product to the customer, envisioned to be a new government to the people of Iraq. The implementation and rollout seemed missing in the plan.
A good project manager thinks through all scenarios, and has a plan for each one. Proper risk management, from a PMI® perspective, would include the negative events, called threats (initiatives take longer than planned, for example) as well as the positive events, called opportunities (initiatives are more successful than planned or take less time than planned, for example). Could it be that the success of the operation happened more quickly than planned and so Rumsfeld and his team were not prepared for the implementation or transition phase? Or maybe certain parts of the initiative were taking longer than planned, in which case a contingency plan was not identified or implemented.
One way or another, it seems the overall plan was incomplete. It does not seem that the initiative was thought through to the end, taking into account various scenarios, alternatives, or nuances, including transition planning to a new status quo or an organizational change management plan to allow stakeholders (the Iraqi people) to get used to and be able to manage the new system, whatever that system may be. A good PM would have accounted for the various scenarios and been ready.
Philosophy aside, by many definitions, this project was not a success, and, as is true for many projects, for many reasons. The warning signs of imminent project failure are many. If there is interest, I’ll explore troubled projects in a future post.
Vicki Wrona, PMP®is the founder and President of Forward Momentum, LLC, an 8(a) consulting and training company found at www.forwardmomentum.net. She has been managing projects and mentoring project managers for the past 20 years in both the private and public sectors. She is an instructor for Global Knowledge and developed GK’s PMP® Exam Prep Boot Camp, part of the program that won PMI’s ® Professional Development Product of the Year Award in 2007. She has trained over 3,300 professionals, including over 1,600 on the PMP® exam. Currently, she is serving on PMI’s® PMBOK® Guide 4th edition creation and review team.
Friday, March 28, 2008
Why Can’t We Just Follow Some Best Practices?
Why Can’t We Just Follow Some Best Practices?
I received a disturbing note from a friend the other day and thought I’d share it with you. His note confirms what I have been seeing, but have been reluctant to admit. This colleague is a project manager working on a project with another company and their project manager. This other PM is a PMP who is also working on his Masters in Project Management. If I were paired up with a PM with these credentials, I would be very happy indeed, thinking that this is ideal. However, my friend wrote that this person is not willing to do the most basic of project management best practices. It was difficult having a kick-off meeting, scheduling status meetings, or collecting status.
Why is that? If this were an isolated case, I could write it off to something like he just must be tired of meetings, or his organizational culture is one that doesn’t follow formal processes. But this isn’t an isolated case. He was writing me to compare notes and ask if I had seen this before. Unfortunately, I have to say ‘yes’. We all talk a good game in theory, but when push comes to shove, why can’t we follow through and do what we say we are going to do? Is it lack of management support? Overwork? A ‘get it done’ mentality?
There’s never time to plan, but always time to fix. Not enough priority or visibility until the project is in jeopardy. Why must we wait until the situation is dire to do the right thing? Can’t we learn from these experiences? I am sure a lot of PMs would like to sleep better at night, knowing they are acting proactively and with management’s support, rather than fighting an uphill battle. If you have thoughts on how to turn this trend, please write and let me know. Maybe we’ll explore this topic deeper in future postings.
Vicki Wrona, PMP®is the founder and President of Forward Momentum, LLC, an 8(a) consulting and training company found at www.forwardmomentum.net. She has been managing projects and mentoring project managers for the past 20 years in both the private and public sectors. She is an instructor for Global Knowledge and developed GK’s PMP® Exam Prep Boot Camp, part of the program that won PMI’s ® Professional Development Product of the Year Award in 2007. She has trained over 3,300 professionals, including over 1,600 on the PMP® exam. Currently, she is serving on PMI’s® PMBOK® Guide 4th edition creation and review team.
I received a disturbing note from a friend the other day and thought I’d share it with you. His note confirms what I have been seeing, but have been reluctant to admit. This colleague is a project manager working on a project with another company and their project manager. This other PM is a PMP who is also working on his Masters in Project Management. If I were paired up with a PM with these credentials, I would be very happy indeed, thinking that this is ideal. However, my friend wrote that this person is not willing to do the most basic of project management best practices. It was difficult having a kick-off meeting, scheduling status meetings, or collecting status.
Why is that? If this were an isolated case, I could write it off to something like he just must be tired of meetings, or his organizational culture is one that doesn’t follow formal processes. But this isn’t an isolated case. He was writing me to compare notes and ask if I had seen this before. Unfortunately, I have to say ‘yes’. We all talk a good game in theory, but when push comes to shove, why can’t we follow through and do what we say we are going to do? Is it lack of management support? Overwork? A ‘get it done’ mentality?
There’s never time to plan, but always time to fix. Not enough priority or visibility until the project is in jeopardy. Why must we wait until the situation is dire to do the right thing? Can’t we learn from these experiences? I am sure a lot of PMs would like to sleep better at night, knowing they are acting proactively and with management’s support, rather than fighting an uphill battle. If you have thoughts on how to turn this trend, please write and let me know. Maybe we’ll explore this topic deeper in future postings.
Vicki Wrona, PMP®is the founder and President of Forward Momentum, LLC, an 8(a) consulting and training company found at www.forwardmomentum.net. She has been managing projects and mentoring project managers for the past 20 years in both the private and public sectors. She is an instructor for Global Knowledge and developed GK’s PMP® Exam Prep Boot Camp, part of the program that won PMI’s ® Professional Development Product of the Year Award in 2007. She has trained over 3,300 professionals, including over 1,600 on the PMP® exam. Currently, she is serving on PMI’s® PMBOK® Guide 4th edition creation and review team.
A Difference of Opinion
A Difference of Opinion
I have a tool that I love to use because I find it to be extremely helpful in running my projects. I will share it with you now, partly because I really believe in this tool, and partly because I have recently seen it used ‘incorrectly’, in my opinion. This is, as my colleague and I have agreed, a professional difference of opinion, as he believes he is right, and I believe I am. I would love to get your opinion on this.
I call this tool The Flexibility Matrix. It is based on the triple constraint concept, and is a terrific tool for understanding where your main constraints really are and to open up dialogue between you, the sponsor, and the customer at the beginning of a project or at first when you take over a project, if it was not previously done. The Flexibility Matrix looks like this:
Least Flexible Moderately Flexible Most Flexible
Scope
Time
Resources/Cost
Constraint Optimize PM Control
The idea is that one ‘X’ goes in each column (no cheating!). As the project manager, try to have the following discussion with both the sponsor and customer together. If you cannot, then meet with the sponsor first and ask them which constraint (time, cost, or scope) is most flexible. Of course, their answer is always ‘none, I want them all’. After you explain to them that you will do your very best to deliver everything and that you want to deliver success so they can look good, but if push comes to shove, you need to know which of the constraints has some flexibility. An experienced or logical sponsor will understand where you are going and finally give you the answer you are looking for. Then repeat the drill with the customer. Compare the two matrices, or sets of expectations. Since you obviously cannot deliver two different set of expectations, if the two tables do not match, get the sponsor and customer together so they can decide between them the project’s true constraint vs greatest flexibility.
So far, so good. This is how I use the tool, and as I said, I love it for its ability to create an early dialogue, understand and set expectations, know my true constraints, and give me a tool to help evaluate change requests. For example, if scope is the most flexible and time is least, then I will not accept a change request that will threaten my end delivery date. Also, I will not accept a change that will increase scope because that is the one area I can decrease, if necessary.
However, I just found out that a colleague of mine uses this matrix with four constraints, listing quality as the last constraint. I disagree with this, saying that quality is not really an option. Quality means the product or service works. Asking someone to rank quality as a lower priority is, in my mind, not feasible. In his mind, if the customer is willing to create a product that will only last one year instead of three, that to him is low quality. I prefer to think of it as lower grade, in that it will not last as long. Calling this quality is, I think, misleading, and I try to avoid misconceptions whenever possible. After all, we have enough miscommunication on our projects already. What message are we sending to the team or to the customer if we say that quality has the most flexibility, that it can be sacrificed somewhat if necessary to make time and/or cost and/or scope? In our world, perception is everything. I think that is a dangerous path to walk. Yet, others do. I wonder how well it works for them.
What do you think? Have you ever used a tool similar to this? If so, have you included quality as an option? If you have, has it worked? Please write and let me know.
Vicki Wrona
I have a tool that I love to use because I find it to be extremely helpful in running my projects. I will share it with you now, partly because I really believe in this tool, and partly because I have recently seen it used ‘incorrectly’, in my opinion. This is, as my colleague and I have agreed, a professional difference of opinion, as he believes he is right, and I believe I am. I would love to get your opinion on this.
I call this tool The Flexibility Matrix. It is based on the triple constraint concept, and is a terrific tool for understanding where your main constraints really are and to open up dialogue between you, the sponsor, and the customer at the beginning of a project or at first when you take over a project, if it was not previously done. The Flexibility Matrix looks like this:
Least Flexible Moderately Flexible Most Flexible
Scope
Time
Resources/Cost
Constraint Optimize PM Control
The idea is that one ‘X’ goes in each column (no cheating!). As the project manager, try to have the following discussion with both the sponsor and customer together. If you cannot, then meet with the sponsor first and ask them which constraint (time, cost, or scope) is most flexible. Of course, their answer is always ‘none, I want them all’. After you explain to them that you will do your very best to deliver everything and that you want to deliver success so they can look good, but if push comes to shove, you need to know which of the constraints has some flexibility. An experienced or logical sponsor will understand where you are going and finally give you the answer you are looking for. Then repeat the drill with the customer. Compare the two matrices, or sets of expectations. Since you obviously cannot deliver two different set of expectations, if the two tables do not match, get the sponsor and customer together so they can decide between them the project’s true constraint vs greatest flexibility.
So far, so good. This is how I use the tool, and as I said, I love it for its ability to create an early dialogue, understand and set expectations, know my true constraints, and give me a tool to help evaluate change requests. For example, if scope is the most flexible and time is least, then I will not accept a change request that will threaten my end delivery date. Also, I will not accept a change that will increase scope because that is the one area I can decrease, if necessary.
However, I just found out that a colleague of mine uses this matrix with four constraints, listing quality as the last constraint. I disagree with this, saying that quality is not really an option. Quality means the product or service works. Asking someone to rank quality as a lower priority is, in my mind, not feasible. In his mind, if the customer is willing to create a product that will only last one year instead of three, that to him is low quality. I prefer to think of it as lower grade, in that it will not last as long. Calling this quality is, I think, misleading, and I try to avoid misconceptions whenever possible. After all, we have enough miscommunication on our projects already. What message are we sending to the team or to the customer if we say that quality has the most flexibility, that it can be sacrificed somewhat if necessary to make time and/or cost and/or scope? In our world, perception is everything. I think that is a dangerous path to walk. Yet, others do. I wonder how well it works for them.
What do you think? Have you ever used a tool similar to this? If so, have you included quality as an option? If you have, has it worked? Please write and let me know.
Vicki Wrona
Does the Mis-Use of the Project Manager Title Dilute Our Worth?
As I travel around, working with people from a large variety of private and public sector organizations in various cities, I am dismayed to see the various forms that the Project Manager title takes. Personally, I have had to overcome the perception of what a Project Manager does. Maybe you have had a similar experience. You’re at a party, someone asks you what you do, you tell them you are a Project Manager, and their face either goes blank or it lights up and they excitedly say, “Oh, like on the Apprentice?” (Heavy sigh.) Or they ask if you work in trailers at construction sites. (Some may, but not me.)
More disconcerting is when I am conducting PM training and a person approaches me and says, “I was given a project on Monday, and since I am in training all week it will be implemented before I’m even back in the office!” Or even worse, you turn in a print job at Kinko’s and the name tag of the person behind the counter has their name with ‘Project Manager’ below it. Are these last two really Project Managers? I think not.
When did the lines between project management and operational processes get so blurred? While they have always been blurred a bit, I see this as increasing. Part of it may be because of the prevalence of projects in the IT world. So many things in IT are projects. Some would say that almost everything in IT is a project. Once you have that mindset, that effort includes the smallest of activities, including help desk functions and/or customer tickets. Unfortunately, I see this over and over again.
The problem I have with this is overcoming the perception of ‘the uninformed’ as to what Project Management really is, and why I am commanding the price that I do. Or in having others appreciate the skills that you and I have, with all the complexities and nuances of our job. While many people within the corporate environment do understand (and appreciate) what Project Managers really do, many still do not. Does this mis-use of the PM title make it more difficult for us to get ahead among and with the uninformed (and there are plenty of them)? While we have made great strides in promoting project management as a profession, I think in the end, the answer is ‘yes’, another obstacle has been put in our path.
What do you think? Let me know.
by Vicki Wrona
As I travel around, working with people from a large variety of private and public sector organizations in various cities, I am dismayed to see the various forms that the Project Manager title takes. Personally, I have had to overcome the perception of what a Project Manager does. Maybe you have had a similar experience. You’re at a party, someone asks you what you do, you tell them you are a Project Manager, and their face either goes blank or it lights up and they excitedly say, “Oh, like on the Apprentice?” (Heavy sigh.) Or they ask if you work in trailers at construction sites. (Some may, but not me.)
More disconcerting is when I am conducting PM training and a person approaches me and says, “I was given a project on Monday, and since I am in training all week it will be implemented before I’m even back in the office!” Or even worse, you turn in a print job at Kinko’s and the name tag of the person behind the counter has their name with ‘Project Manager’ below it. Are these last two really Project Managers? I think not.
When did the lines between project management and operational processes get so blurred? While they have always been blurred a bit, I see this as increasing. Part of it may be because of the prevalence of projects in the IT world. So many things in IT are projects. Some would say that almost everything in IT is a project. Once you have that mindset, that effort includes the smallest of activities, including help desk functions and/or customer tickets. Unfortunately, I see this over and over again.
The problem I have with this is overcoming the perception of ‘the uninformed’ as to what Project Management really is, and why I am commanding the price that I do. Or in having others appreciate the skills that you and I have, with all the complexities and nuances of our job. While many people within the corporate environment do understand (and appreciate) what Project Managers really do, many still do not. Does this mis-use of the PM title make it more difficult for us to get ahead among and with the uninformed (and there are plenty of them)? While we have made great strides in promoting project management as a profession, I think in the end, the answer is ‘yes’, another obstacle has been put in our path.
What do you think? Let me know.
by Vicki Wrona
Get Those Rules and Requirements, Part 2
The elicitation, documentation, verification and validation of business requirements is a set of processes that links the IT Service Management Lifecycle (ITSM) with other lifecycle approaches to such as Project Management (PMBOK), Business Analysis (BABOK), and System Development Lifecycle (SDLC). Each of these approaches seeks to identify and understand the business’s vital business functions, internal and external drivers and critical success factors with the goal of matching projects, products and services to defined business objectives.
An IT Service provider may well choose to begin an ITSM implementation with a business analysis to create a baseline “picture” of the business rules and requirements. This point in time understanding can help the IT Service provider to focus Continual Service Improvement (CSI) processes and activities on areas that support vital business functions. Completing a business, or enterprise, analysis also gives the IT Service provider a means of assessing their IT Service Management maturity. Self assessment begins with a good, hard look at where the IT Service provider is right now in terms of providing service value in the areas most important to the customer. A thorough assessment of strengths and weaknesses in the current service model will help the organization identify pain points and plan to address them first. This baseline is the “as is” portion of a common gap analysis.
Simply put, gap analysis consists of four parts: documenting the current state, describing the desired state, measuring the difference (gap), and coming up with a plan to close the gap. Gap analysis is a tool that can be used repeatedly to refine our understanding of a business challenge and clarify our response to each challenge. It is likely that an IT service provider will complete many gap analyses in the course of aligning IT services with changing business needs.
Requirements again take the spotlight when the Service Level Manager works with business customers to negotiate Service Level Agreements. Desired state is the “to be” portion of gap analysis. In this process, business rules are deconstructed into business requirements which are refined into functional and non-functional requirements. Functional and non-functional business requirements are expressed by the customer as service level requirements (SLR). Service Level Targets (SLT), supplied by the IT service organization, defines the current capabilities of the IT infrastructure. The Service Level Management process compares the requirements to the targets and negotiates the differences to create the several types of Service Level Agreements.
The Service Level Manager develops and maintains a relationship with business process owners that keeps the IT Service provider informed about changes to business requirements. Strong analysis and communication skills remain important when developing the service offering and establishing measures of success.
To summarize, Service Design and Continual Service Improvement come together to identify and understand the business requirements that IT Services strive to support. Clear, accurate, validated requirements can save time and money in the design of IT Services. The alignment of business and IT Service visions is both the goal and a key benefit of IT Service Management.
Rhane Thomas
An IT Service provider may well choose to begin an ITSM implementation with a business analysis to create a baseline “picture” of the business rules and requirements. This point in time understanding can help the IT Service provider to focus Continual Service Improvement (CSI) processes and activities on areas that support vital business functions. Completing a business, or enterprise, analysis also gives the IT Service provider a means of assessing their IT Service Management maturity. Self assessment begins with a good, hard look at where the IT Service provider is right now in terms of providing service value in the areas most important to the customer. A thorough assessment of strengths and weaknesses in the current service model will help the organization identify pain points and plan to address them first. This baseline is the “as is” portion of a common gap analysis.
Simply put, gap analysis consists of four parts: documenting the current state, describing the desired state, measuring the difference (gap), and coming up with a plan to close the gap. Gap analysis is a tool that can be used repeatedly to refine our understanding of a business challenge and clarify our response to each challenge. It is likely that an IT service provider will complete many gap analyses in the course of aligning IT services with changing business needs.
Requirements again take the spotlight when the Service Level Manager works with business customers to negotiate Service Level Agreements. Desired state is the “to be” portion of gap analysis. In this process, business rules are deconstructed into business requirements which are refined into functional and non-functional requirements. Functional and non-functional business requirements are expressed by the customer as service level requirements (SLR). Service Level Targets (SLT), supplied by the IT service organization, defines the current capabilities of the IT infrastructure. The Service Level Management process compares the requirements to the targets and negotiates the differences to create the several types of Service Level Agreements.
The Service Level Manager develops and maintains a relationship with business process owners that keeps the IT Service provider informed about changes to business requirements. Strong analysis and communication skills remain important when developing the service offering and establishing measures of success.
To summarize, Service Design and Continual Service Improvement come together to identify and understand the business requirements that IT Services strive to support. Clear, accurate, validated requirements can save time and money in the design of IT Services. The alignment of business and IT Service visions is both the goal and a key benefit of IT Service Management.
Rhane Thomas
Get Those Rules and Requirements, Part 1
One of the clear goals of the IT Service Management (ITSM) approach is to create and support alignment between business goals and IT Services. To that end, the IT organization develops a specialized set of capabilities to deliver value to the business in the form of products and services. It should be obvious that a keen understanding of the business vision, mission and goals is necessary as a foundation for designing those products and services. How does the IT Service organization build the foundation? By learning and understanding the business rules and business requirements.
Simply put, business rules are those things that business must or must not do in order to exist and operate. Business rules originate from laws, regulations, contracts, and similar external drivers. Business rules guide the business’ behavior and circumscribe the “what” of a business, answering the question, “What business are we in?” How you choose to implement or enforce the rules is a different matter.
Business requirements define the conditions or capabilities needed to meet a business objective or solve a business problem. Requirements are statements that tell you what must be done to enable the implementation of and compliance with a business rule. Normally expressed in terms of desired outcomes, business requirements answer the question, “What do we need to conduct our business?” In ITSM, the goal is to create and maintain technology-based services that support fulfilling the business requirements.
Functional requirements describe what a product or service has to do to fulfill the business requirement(s). Functional requirements may be referred to as System Requirements, and can be in a many-to-one relationship with a business requirement.
Non Functional requirements describe how the product or service will fulfill the business requirement(s). They are requirements that specify attributes of the functional requirements, e.g. performance, scalability, security and usability requirements. Often nonfunctional requirements may be referred as the “ilities”. This is because many of them are expressed in terms like scalability, reliability, usability, stability, manageability, etc. The processes in the Service Design domain help the IT Service provider to discover, document, define and quantify these desirable attributes of a product or service as nonfunctional requirements.
How does the IT Service provider find out about the business rules or requirements? By developing and maintaining strong relationships with the customers. Documents such as vision statements, budget justifications, and internal procedures can be resources for matching IT services to business goals. Tools such as workshops, interviews, brainstorming, focus groups and the Service Knowledge Management System (SKMS) can assist the IT Service provider in developing and maintaining a deeper understanding of the business perspective. This is a valuable tool for identifying opportunities to align IT products and services with specific business goals and objectives. The Service Design domain, which contains the Service Level Management Process, concerns itself with customer relations.
Rhane Thomas
Simply put, business rules are those things that business must or must not do in order to exist and operate. Business rules originate from laws, regulations, contracts, and similar external drivers. Business rules guide the business’ behavior and circumscribe the “what” of a business, answering the question, “What business are we in?” How you choose to implement or enforce the rules is a different matter.
Business requirements define the conditions or capabilities needed to meet a business objective or solve a business problem. Requirements are statements that tell you what must be done to enable the implementation of and compliance with a business rule. Normally expressed in terms of desired outcomes, business requirements answer the question, “What do we need to conduct our business?” In ITSM, the goal is to create and maintain technology-based services that support fulfilling the business requirements.
Functional requirements describe what a product or service has to do to fulfill the business requirement(s). Functional requirements may be referred to as System Requirements, and can be in a many-to-one relationship with a business requirement.
Non Functional requirements describe how the product or service will fulfill the business requirement(s). They are requirements that specify attributes of the functional requirements, e.g. performance, scalability, security and usability requirements. Often nonfunctional requirements may be referred as the “ilities”. This is because many of them are expressed in terms like scalability, reliability, usability, stability, manageability, etc. The processes in the Service Design domain help the IT Service provider to discover, document, define and quantify these desirable attributes of a product or service as nonfunctional requirements.
How does the IT Service provider find out about the business rules or requirements? By developing and maintaining strong relationships with the customers. Documents such as vision statements, budget justifications, and internal procedures can be resources for matching IT services to business goals. Tools such as workshops, interviews, brainstorming, focus groups and the Service Knowledge Management System (SKMS) can assist the IT Service provider in developing and maintaining a deeper understanding of the business perspective. This is a valuable tool for identifying opportunities to align IT products and services with specific business goals and objectives. The Service Design domain, which contains the Service Level Management Process, concerns itself with customer relations.
Rhane Thomas
What is Customer Focus? Part Two
In my previous post I began the story of how my quest to use a wireless connectivity feature in my notebook computer gave me a new perspective on how the IT Service Management framework can add value to the IT service organization and, ultimately, to the business as a whole.
While trying to activate and use the built-in broadband wireless connectivity in my new notebook computer, I have ping ponged between the technical support lines of the computer manufacturer and the wireless carrier.
Several days, phone calls and web chat sessions followed before a different technician on the manufacturer’s Service Desk asked if I had activated my wireless phone number. He described the process and that’s when I found out that the telephone service carrier’s online process hadn’t provided all the information necessary to actually use the service. I thanked the technician and once again called technical support number at the wireless carrier.
Thanks to the computer company’s technician I learned that I needed to contact the wireless provider to get an activation code and MSID to activate and configure the preinstalled software. A technician at the wireless carrier heard my problem and quickly provided the missing pieces of information. Foolishly confident, I opened the software and attempted to enter the activation codes following the simple prompts provided.
The result was an error that had me right on the phone and web with the computer manufacturer’s Service Desk. Three simple steps, executed in order, and still no connectivity. Computer support, apparently not having read the open ticket tried to have me reinstall software a second time. We went through the same process again and got the same result… no connectivity. The computer manufacturer’s technician suggested that the wireless carrier had given me bad numbers. The score: 14 days, 7 calls, 6 e-chats and still no connectivity. On day 14 I gave up and cancelled the wireless broadband account because neither side could make it work.
As a customer of this partnership between computer manufacturer and wireless provider, I have a poorer opinion of both companies than before. They did not follow even the simple Deming PDCA level of quality management. A customer focused organization would not have stopped until my problem was accurately diagnosed, the root cause identified and the problem resolved to my satisfaction.
How could a framework like ITSM have helped in this situation? One, clear unambiguous escalation processes would have brought more technical expertise to bear on my question before I was bounced back and forth repeatedly. Two, a central knowledge repository would have made the history of my contacts available to all the technicians I spoke with allowing them to get more information from me rather than asking the same questions over and over. Three, a customer focus would have trained the Service Desk staff to listen and probe to assure that the customer problem or desire was fully and accurately captured before a course of action was taken. Four, mature problem management processes would have focused on assuring that my problem was completed resolved and full functionality of computer broadband capability restored.
This story is not quite over as I took the next logical step as a consumer and wrote a letter via “snail mail” to the Chief Marketing Officer of the computer company to let them know how unhappy I am with the service I received.
While trying to activate and use the built-in broadband wireless connectivity in my new notebook computer, I have ping ponged between the technical support lines of the computer manufacturer and the wireless carrier.
Several days, phone calls and web chat sessions followed before a different technician on the manufacturer’s Service Desk asked if I had activated my wireless phone number. He described the process and that’s when I found out that the telephone service carrier’s online process hadn’t provided all the information necessary to actually use the service. I thanked the technician and once again called technical support number at the wireless carrier.
Thanks to the computer company’s technician I learned that I needed to contact the wireless provider to get an activation code and MSID to activate and configure the preinstalled software. A technician at the wireless carrier heard my problem and quickly provided the missing pieces of information. Foolishly confident, I opened the software and attempted to enter the activation codes following the simple prompts provided.
The result was an error that had me right on the phone and web with the computer manufacturer’s Service Desk. Three simple steps, executed in order, and still no connectivity. Computer support, apparently not having read the open ticket tried to have me reinstall software a second time. We went through the same process again and got the same result… no connectivity. The computer manufacturer’s technician suggested that the wireless carrier had given me bad numbers. The score: 14 days, 7 calls, 6 e-chats and still no connectivity. On day 14 I gave up and cancelled the wireless broadband account because neither side could make it work.
As a customer of this partnership between computer manufacturer and wireless provider, I have a poorer opinion of both companies than before. They did not follow even the simple Deming PDCA level of quality management. A customer focused organization would not have stopped until my problem was accurately diagnosed, the root cause identified and the problem resolved to my satisfaction.
How could a framework like ITSM have helped in this situation? One, clear unambiguous escalation processes would have brought more technical expertise to bear on my question before I was bounced back and forth repeatedly. Two, a central knowledge repository would have made the history of my contacts available to all the technicians I spoke with allowing them to get more information from me rather than asking the same questions over and over. Three, a customer focus would have trained the Service Desk staff to listen and probe to assure that the customer problem or desire was fully and accurately captured before a course of action was taken. Four, mature problem management processes would have focused on assuring that my problem was completed resolved and full functionality of computer broadband capability restored.
This story is not quite over as I took the next logical step as a consumer and wrote a letter via “snail mail” to the Chief Marketing Officer of the computer company to let them know how unhappy I am with the service I received.
Rhane Thomas
What is Customer Focus?
Lots of books and whitepapers have been written about customer service and the ‘customer focus’, what does it mean in practical terms? As a consumer of products and services myself, I can share what it means to me.
First, and foremost, it means listening and attending to what the customer is saying. Too often, service desk and call center staff go through a standard set of questions by rote that do not get them the information needed to accurately understand the customer’s concern. The active listening ideal suggests asking open-ended questions and rephrasing the customer’s comments to be sure that real communication has taken place.
Second, customer focus means assuring that the customer is satisfied both with the service received and with the form and style of delivery.
In IT Service Management, the Service Desk is the single point of contact (SPOC) for customers consuming IT services. As the first and maybe only direct experience a customer will have with service provider, a customer focus is essential for building and maintaining a positive reputation for quality. Active listening is one of skills that is essential for Service Desk staff.
In service provision the customer’s perception of quality is everything. A recent experience with the Service Desks of two large technology companies spotlighted the value that a framework like IT Service Management can bring to service provision and to managing the customers’ perceptions. My personal journey to realize the value of a product and service I purchase illustrates some very common pitfalls that good processes might avoid.
The notebook computer I use for teaching my classes was purchased with a built-in broadband modem. One month of free service with a national carrier was offered as an incentive for purchasing that particular model. While on the road, I needed connectivity and decided to accept the trial offer. I followed a preinstalled web link and completed an application for service with the wireless carrier. At the end of the self-service web application process, I had a phone number and a message saying I had completed the application process. Unfortunately, that was not enough to actually use the broadband feature.
Blissfully ignorant, I tried to connect using the broadband feature the next day and was unable to complete the wireless connection. I contacted the notebook manufacturer’s tech support site and began to explain my problem to the technician. He directed me through an exhaustive and totally unnecessary process of removing and reinstalling drivers and programs that did not ultimately resolve my problem. He suggested that I contact the wireless carrier.
I visited one of the wireless carrier’s store fronts and was sent to a second location that I was told provided hardware technical support. A short drive across town and I learned that the wireless carrier does not service the module in the notebook computer. They could not offer any help with my connectivity issue, but did ask me to set up a PIN number for my, thus far useless, wireless account. The very pleasant service person suggested I call the notebook manufacturer.
To be continued…
Posted by Rhane Thomas
First, and foremost, it means listening and attending to what the customer is saying. Too often, service desk and call center staff go through a standard set of questions by rote that do not get them the information needed to accurately understand the customer’s concern. The active listening ideal suggests asking open-ended questions and rephrasing the customer’s comments to be sure that real communication has taken place.
Second, customer focus means assuring that the customer is satisfied both with the service received and with the form and style of delivery.
In IT Service Management, the Service Desk is the single point of contact (SPOC) for customers consuming IT services. As the first and maybe only direct experience a customer will have with service provider, a customer focus is essential for building and maintaining a positive reputation for quality. Active listening is one of skills that is essential for Service Desk staff.
In service provision the customer’s perception of quality is everything. A recent experience with the Service Desks of two large technology companies spotlighted the value that a framework like IT Service Management can bring to service provision and to managing the customers’ perceptions. My personal journey to realize the value of a product and service I purchase illustrates some very common pitfalls that good processes might avoid.
The notebook computer I use for teaching my classes was purchased with a built-in broadband modem. One month of free service with a national carrier was offered as an incentive for purchasing that particular model. While on the road, I needed connectivity and decided to accept the trial offer. I followed a preinstalled web link and completed an application for service with the wireless carrier. At the end of the self-service web application process, I had a phone number and a message saying I had completed the application process. Unfortunately, that was not enough to actually use the broadband feature.
Blissfully ignorant, I tried to connect using the broadband feature the next day and was unable to complete the wireless connection. I contacted the notebook manufacturer’s tech support site and began to explain my problem to the technician. He directed me through an exhaustive and totally unnecessary process of removing and reinstalling drivers and programs that did not ultimately resolve my problem. He suggested that I contact the wireless carrier.
I visited one of the wireless carrier’s store fronts and was sent to a second location that I was told provided hardware technical support. A short drive across town and I learned that the wireless carrier does not service the module in the notebook computer. They could not offer any help with my connectivity issue, but did ask me to set up a PIN number for my, thus far useless, wireless account. The very pleasant service person suggested I call the notebook manufacturer.
To be continued…
Posted by Rhane Thomas
It’s the people. . .
Lately I’ve been teaching ITIL v3 Foundations Boot Camps. One theme has occurred again and again in the comments and questions from participants, “Where and how do you start?” My advice is to start with the people. Both the people who work in IT and the people in the larger business have to be considered when planning for the organizational changes that an ITIL implementation can bring. Although ITIL is focused on transforming how Information Technology is delivered, sustained and perceived within the larger business context, the framework clearly assumes that changes will be required on both sides of the relationship.
While books and experts are often quoted saying that ITIL cannot be implemented piecemeal, it is fairly clear that sweeping organizational change cannot be accomplished in an instant. The key to understanding the assertion is in the interrelatedness of the five ITIL domains. Within each domain and across all the domains an output of one process is a necessary input to another.
Businesses considering an ITIL implementation are most often well established and unable and unwilling to suspend operations to completely change their organization and ways of doing business over night. Thus, the move toward an IT Service Management mindset most often starts with Continual Service Improvement (CSI). At the most basic level, ITIL provides a shared vocabulary and set of assumptions to help IT and business collaborate on improving processes and IT support of them.
CSI is the ITIL domain that concerns itself with transforming the way in which business interacts with its Information Technology assets and resources. This is where the people come in. People are what makes processes live. In order to effectively transform an organization, you have to win the cooperation of the people who will ultimately do the work. In order to move people out of their comfort zones, it is imperative that the introduction of Continual Service Improvement be done in a way that makes the benefits of CSI to both the business and the individual clear.People envision the work, set the value of work and actually do the work of business both inside and outside IT. ITIL stresses the importance of clear and unambiguous accountability for processes, i.e., ownership. Empowering people to own business processes and be instrumental in the success of business initiatives that depend on them, makes the benefits of Continual Service Improvement clear. The establishment of accountability and ownership arguably lead to process documentation if for no other reason than having justification for actions and an audit trail. Documentation of current practices, or how business gets done, become the jumping off point for CSI. A CSI implementation can begin with very small incremental improvements, providing a series of small “wins” which may increase acceptance of the CSI concept and demonstrate the value of increased process rigor. Although ITIL is focused on transforming Information Technology, the concept of process ownership and accountability is equally applicable to non-IT business concerns, and the value of good documentation as a business case for planned, controlled change applies enterprise wide.
Posted by Rhané Thomas
While books and experts are often quoted saying that ITIL cannot be implemented piecemeal, it is fairly clear that sweeping organizational change cannot be accomplished in an instant. The key to understanding the assertion is in the interrelatedness of the five ITIL domains. Within each domain and across all the domains an output of one process is a necessary input to another.
Businesses considering an ITIL implementation are most often well established and unable and unwilling to suspend operations to completely change their organization and ways of doing business over night. Thus, the move toward an IT Service Management mindset most often starts with Continual Service Improvement (CSI). At the most basic level, ITIL provides a shared vocabulary and set of assumptions to help IT and business collaborate on improving processes and IT support of them.
CSI is the ITIL domain that concerns itself with transforming the way in which business interacts with its Information Technology assets and resources. This is where the people come in. People are what makes processes live. In order to effectively transform an organization, you have to win the cooperation of the people who will ultimately do the work. In order to move people out of their comfort zones, it is imperative that the introduction of Continual Service Improvement be done in a way that makes the benefits of CSI to both the business and the individual clear.People envision the work, set the value of work and actually do the work of business both inside and outside IT. ITIL stresses the importance of clear and unambiguous accountability for processes, i.e., ownership. Empowering people to own business processes and be instrumental in the success of business initiatives that depend on them, makes the benefits of Continual Service Improvement clear. The establishment of accountability and ownership arguably lead to process documentation if for no other reason than having justification for actions and an audit trail. Documentation of current practices, or how business gets done, become the jumping off point for CSI. A CSI implementation can begin with very small incremental improvements, providing a series of small “wins” which may increase acceptance of the CSI concept and demonstrate the value of increased process rigor. Although ITIL is focused on transforming Information Technology, the concept of process ownership and accountability is equally applicable to non-IT business concerns, and the value of good documentation as a business case for planned, controlled change applies enterprise wide.
Posted by Rhané Thomas
Subscribe to:
Posts (Atom)