top
Sort by :

ITIL Practitioner – Things To Be Aware Of

ITIL stands for Information Technology Infrastructure Library and it is a set of libraries to help professionals cover different aspects of managing an IT Service project. Whether you provide a service as a vendor company or your product is marketed as a service to the world; in both cases, ITIL framework is suitable. Currently, Version 3 of ITIL framework is in existence and it contains 5 volumes dealing with Service Strategy, Service Design, Service Operation, Service transition and continual service improvement. This existing version known as ITIL V3 came into being in the year 2011. Initially, ITIL framework categorized the professionals into foundation course, intermediate level, expert level and master level. However, in the year 2015, AXELOS introduced one supplementary certification known as ITIL practitioner. This certification is meant to complement the professionals who are already on their way to become an Expert or a Master and in no way is it compulsory for them to clear it.  However, it will add 3 credit points to your journey of becoming an expert if you choose to add this to your profile. And it will add 15 points to your ITIL badge for professional competency development. Must-read primer on the new ITIL Practitioner Guidance via @stephenmann https://t.co/LDb46lcRfp @Joe_the_IT_guy pic.twitter.com/vmM9RX2kUO — Greg Sanker (@gtsanker) March 9, 2016 I am a newbie, please tell me about ITIL Practitioner level By the term newbie, I am considering anyone who has heard about ITIL certification framework, or might have come across some ITIL professionals in their network or official circles but does not know exactly what it entails. First of all, ITIL practitioner level was introduced by the governing council not only to add one stepping stone for the professionals who are familiar with the definitions and technical terms of ITIL Course, but also, to allow them the additional benefit of understanding how to apply these terms and knowledge in the real world. Practitioners are professionals who understand the ITSM [Information Technology Service management] framework, know how it fits the big picture and how to use it. These professionals are the ones who use this knowledge on a daily basis as part of their projects. In order to become an ITIL practitioner, one needs to clear the ITIL foundation exam. However, being practitioner level certified is not compulsory to attempt becoming Intermediate level certified.   What knowledge is contained in ITIL framework in general or for ITIL Practitioner? In version 2 of ITIL framework, there used to be a certification for “ITIL service practitioner”; in version 3, that has been removed and this ITIL Practitioner is different from that one. So do not get confused. Both are different from each other. Additionally, out of the 5 volumes of ITIL framework, Service strategy volume is considered to be the core of ITIL framework and once you develop the understanding of all 5 volumes, I am sure you will agree with me too. In the upcoming post, I will briefly speak about this point. ITIL practitioner exam consists of 40 scenario-based questions that you have to answer in the form of multiple choice questions within 135 minutes. This is an open book exam where you are allowed to carry the ITIL practitioner guide with you. You need to have 70% marks to be certified as ITIL practitioner. Once you subscribe to the course of ITIL practitioner, you will get access to ITIL core library providing you an information about planning to implement service management, ITIL practitioner guide and a toolkit containing existing publication, worksheets, templates, case studies, and scenarios. These resources will not only help you in clearing the exam, but will also prove useful to you in your day-to-day work.     Which job roles are most suited for the ITIL certified and how will it help me and my organization? As you must have understood by now, if you are working in a service-based, information technology industry then this framework is useful for you. But if you are working in any of these job roles then it is highly recommended to get ITIL certified: IT managers or Support staff Analysts Operations Managers Process owners Database administrators Consultants or Architects Service application developers It will help you in two ways: It will help you make informed and educated decisions about process, practices to be followed in your project It will increase the weightage of your resume, leading to better job prospects, especially for the UK-based clients. It will help your clients and company in a way that they will get the confidence that their project is in better hands, they can rely on you to provide a standard way of delivering the “service”. So overall, it helps everyone. How can an #ITIL qualification help you advance your career? #ITjobs https://t.co/CT4aY8MoJf — IT Governance (@ITGovernance) January 25, 2018 Adopt and Adapt – What is it? “Adopt and Adapt” – Sounds like a mantra given by some great marketing guru or a lesson from elite Management class, isn’t it? Well, it could be. But in this context, this is the guiding principle of ITIL. ITIL framework is one of the main proponents of this concept that states that once you understand a new or better practice, whether it is from ITSM library or from industry, then you adopt it in your project. But before doing so, you need to apply your domain knowledge, your existing constraints and your upcoming opportunities, to modify that practice to make it suitable for your needs. Since ITIL does not believe in the concept of one size fits all, therefore, adaptation is necessary. Else you are doomed to failure through the same means that you hoped to use for your success. While adapting, you also need to review your existing strategy, your transition plans, and your existing processes to know if there is a redundancy. And if such redundancy exists then you need to apply your critical thinking or even call for a brainstorming session and merge the processes into a single and a more effective way. This is “Adopt and Adapt” way of working for ITIL professionals. Lastly, what other benefits will I gain if become an ITIL practitioner? First of all, you will learn how to apply the knowledge of ITIL framework to the real-world projects on the ground. So in short, you will gain practical experience. And as we all know, theory and practice differ vastly from each other. One more benefit is that you will be able to help other individuals in your project and company to leverage continually and improve the service through measurements and maximize benefits by taking the right steps. And most importantly, you will be able to integrate well with the ITIL community and will be on a firm step towards your journey of becoming an expert or a master. So should I take this certification and become an ITIL practitioner? Yes, You should! If you are an Information technology professional dealing with service-related projects or products, then you should get ITIL Practitioner certified. KnowledgeHut is a certified and approved knowledge training provider to help you get certified. Contact support staff at KnowledgeHut to get enrolled. All the best!  
ITIL Practitioner – Things To Be Aware Of
Abhinav
Rated /5 based on 2 customer reviews
Abhinav

Abhinav Gupta

Blog Author

PMP, has 12+ years of experience working in Information technology sector and has worked with companies like Infosys and Microsoft in various capacities. He started his career as a manual tester for a world renowned software product and grew on to become automation champion in both functional as well as UI. He has worked with Healthcare units providing various software solutions to companies in North America and has worked with search engine based groups to enhance their experience and provide more bang for buck to their customers.

ITIL Practitioner – Things To Be Aware Of

ITIL stands for Information Technology Infrastructure Library and it is a set of libraries to help professionals cover different aspects of managing an IT Service project. Whether you provide a service as a vendor company or your product is marketed as a service to the world; in both cases, ITIL framework is suitable. Currently, Version 3 of ITIL framework is in existence and it contains 5 volumes dealing with Service Strategy, Service Design, Service Operation, Service transition and continual service improvement. This existing version known as ITIL V3 came into being in the year 2011. Initially, ITIL framework categorized the professionals into foundation course, intermediate level, expert level and master level. However, in the year 2015, AXELOS introduced one supplementary certification known as ITIL practitioner. This certification is meant to complement the professionals who are already on their way to become an Expert or a Master and in no way is it compulsory for them to clear it.  However, it will add 3 credit points to your journey of becoming an expert if you choose to add this to your profile. And it will add 15 points to your ITIL badge for professional competency development. Must-read primer on the new ITIL Practitioner Guidance via @stephenmann https://t.co/LDb46lcRfp @Joe_the_IT_guy pic.twitter.com/vmM9RX2kUO — Greg Sanker (@gtsanker) March 9, 2016 I am a newbie, please tell me about ITIL Practitioner level By the term newbie, I am considering anyone who has heard about ITIL certification framework, or might have come across some ITIL professionals in their network or official circles but does not know exactly what it entails. First of all, ITIL practitioner level was introduced by the governing council not only to add one stepping stone for the professionals who are familiar with the definitions and technical terms of ITIL Course, but also, to allow them the additional benefit of understanding how to apply these terms and knowledge in the real world. Practitioners are professionals who understand the ITSM [Information Technology Service management] framework, know how it fits the big picture and how to use it. These professionals are the ones who use this knowledge on a daily basis as part of their projects. In order to become an ITIL practitioner, one needs to clear the ITIL foundation exam. However, being practitioner level certified is not compulsory to attempt becoming Intermediate level certified.   What knowledge is contained in ITIL framework in general or for ITIL Practitioner? In version 2 of ITIL framework, there used to be a certification for “ITIL service practitioner”; in version 3, that has been removed and this ITIL Practitioner is different from that one. So do not get confused. Both are different from each other. Additionally, out of the 5 volumes of ITIL framework, Service strategy volume is considered to be the core of ITIL framework and once you develop the understanding of all 5 volumes, I am sure you will agree with me too. In the upcoming post, I will briefly speak about this point. ITIL practitioner exam consists of 40 scenario-based questions that you have to answer in the form of multiple choice questions within 135 minutes. This is an open book exam where you are allowed to carry the ITIL practitioner guide with you. You need to have 70% marks to be certified as ITIL practitioner. Once you subscribe to the course of ITIL practitioner, you will get access to ITIL core library providing you an information about planning to implement service management, ITIL practitioner guide and a toolkit containing existing publication, worksheets, templates, case studies, and scenarios. These resources will not only help you in clearing the exam, but will also prove useful to you in your day-to-day work.     Which job roles are most suited for the ITIL certified and how will it help me and my organization? As you must have understood by now, if you are working in a service-based, information technology industry then this framework is useful for you. But if you are working in any of these job roles then it is highly recommended to get ITIL certified: IT managers or Support staff Analysts Operations Managers Process owners Database administrators Consultants or Architects Service application developers It will help you in two ways: It will help you make informed and educated decisions about process, practices to be followed in your project It will increase the weightage of your resume, leading to better job prospects, especially for the UK-based clients. It will help your clients and company in a way that they will get the confidence that their project is in better hands, they can rely on you to provide a standard way of delivering the “service”. So overall, it helps everyone. How can an #ITIL qualification help you advance your career? #ITjobs https://t.co/CT4aY8MoJf — IT Governance (@ITGovernance) January 25, 2018 Adopt and Adapt – What is it? “Adopt and Adapt” – Sounds like a mantra given by some great marketing guru or a lesson from elite Management class, isn’t it? Well, it could be. But in this context, this is the guiding principle of ITIL. ITIL framework is one of the main proponents of this concept that states that once you understand a new or better practice, whether it is from ITSM library or from industry, then you adopt it in your project. But before doing so, you need to apply your domain knowledge, your existing constraints and your upcoming opportunities, to modify that practice to make it suitable for your needs. Since ITIL does not believe in the concept of one size fits all, therefore, adaptation is necessary. Else you are doomed to failure through the same means that you hoped to use for your success. While adapting, you also need to review your existing strategy, your transition plans, and your existing processes to know if there is a redundancy. And if such redundancy exists then you need to apply your critical thinking or even call for a brainstorming session and merge the processes into a single and a more effective way. This is “Adopt and Adapt” way of working for ITIL professionals. Lastly, what other benefits will I gain if become an ITIL practitioner? First of all, you will learn how to apply the knowledge of ITIL framework to the real-world projects on the ground. So in short, you will gain practical experience. And as we all know, theory and practice differ vastly from each other. One more benefit is that you will be able to help other individuals in your project and company to leverage continually and improve the service through measurements and maximize benefits by taking the right steps. And most importantly, you will be able to integrate well with the ITIL community and will be on a firm step towards your journey of becoming an expert or a master. So should I take this certification and become an ITIL practitioner? Yes, You should! If you are an Information technology professional dealing with service-related projects or products, then you should get ITIL Practitioner certified. KnowledgeHut is a certified and approved knowledge training provider to help you get certified. Contact support staff at KnowledgeHut to get enrolled. All the best!  
ITIL Practitioner – Things To Be Aware Of
Author Image
Rated /5 based on 2 customer reviews
ITIL Practitioner – Things To Be Aware Of

ITIL Practitioner – Things To Be Aware Of

Abhinav Gupta
ITIL stands for Information Technology Infrastructure Library and it is a set of libraries to help professionals cover different aspects of managing an IT Service project. Whether you provide a servic...
Continue reading

10 deadly myths of Agile and Scrum

Agile and Scrum have been conquering the minds of engineers, managers especially from software industry quite effectively since last few years. The impact is so much so that every software engineer thinks that if he/she is not working on an Agile or Scrum project, their career is not going anywhere! Sounds funny, right? It surely is, but so is the reality of this fact.  Agile and Scrum have become so pervasive in our thought process that we as engineers or managers or product owners do not stop to ask ourselves once if we really need any Agile methodologies to complete the project at hand or not. We simply assume that we are going to follow Agile and Scrum. While I do not have any problem with Agile or Scrum as such, I do have concerns when I see people following things that are wrong; wrong as in incorrect even from an Agile manifesto perspective. These bad practices or even myths [as we can safely call them due to lack of a better word] have crept in due to our insufficient understanding of the manifesto or Scrum alliance guidelines owing to the rush of getting onto the Agile train before it leaves us high and dry. And the impact of this short sightedness is the fact that we are adhering to mistakes in project execution techniques based on some popular concepts, because no one knows they are myths and have no resemblance to truth. It is possible that these mistakes might be causing the issues in your project execution. Through this article, I am trying to share with you some of the most common myths or misunderstandings that people have with respect to Agile and Scrum. Myths and Legends of Agile- only software? via @adrian_stalham #waterfall #scrum #agile pic.twitter.com/TDXFrSthUC — Pat Lynes (@patlynes) 10 October 2017 Do go through them and let me know your take on this. Let’s start! Myth 1: Anybody can become a scrum master Reality: A Scrum Master is supposed to be the person who does not involve personally into the discussions going on in the sprints and daily stand-ups and keeps his eyes on the goal even when emotions are running high during the Scrum meeting. So yes, anybody can become a Scrum Master playing many roles as long as they have emotional intelligence to deal with the varied opinions, discussions, and tendencies to derail the team away from the goal. Hence, in reality, emotional intelligence is the most important prerequisite to become a Scrum Master. Myth 2: More meetings mean Scrum is going well Reality: Scrum was supposed to be meeting-free except for the 5 known time boxed events [kick off, planning, scrum status, review, and post-mortem]. Apart from this, there are no more meetings required. And if your schedule is filled with multitude of so-called short meetings, then it is a clear sign that something is not right in the way Scrum is being done in your team. Hence, the reality becomes, more meetings mean your Scrum is going ‘into’ the ‘well’. Myth 3: Daily scrum meeting is same as the status meeting. Reality: Nothing could be further from the truth and intention if we think that daily scrum meeting is same as that of status meeting. It is not! You must have seen multiple instances where team members give updates on what we did yesterday and what we plan to do today; they discuss issues and leave assuming that today’s scrum was successful. In reality, that is a failure. Scrum meeting is supposed to get together and quickly review the overall progress of the project based on efforts till last night against the end goal of project and quickly gauge if we are on track or not. That is followed by status meeting, where today’s tasks are quickly distributed along with the status check of in-flight items. That’s how it should be. Myth 4: Velocity and Value are the same thing. Reality: This is so wrong on many fronts. This assumption implies that if a work is being done quickly then it is taking us towards the end goal. Is that true? Say a team member is creating automation with high velocity. But is it taking you closer towards shipping the product by the end date? No right? Similarly, during Scrum meetings, we focus on the Value of work being done. It is possible that 100% of yesterday’s efforts might have contributed to 10% of total value. That is fine, as long as your idea of velocity and value is clear. Velocity is checked during status meeting; just to be clear. Velocity leads us to Value. Myth 5: Only a technical person can become a Scrum master Reality: I want to correct that statement by saying a technical person can be made a Scrum master as long as they can ensure that they do not let their technical impulses interfere with their duties of being a Scrum Master. If that cannot be guaranteed, then it is better to choose a non-technical person to be a Scrum Master because they can then ensure that the discussions do not cross the time limits and the meeting’s focus remains sharp. Myth 6: Sprint 0 is a must Reality: These days it has become a norm to have the first sprint as a “blank Sprint” to allow teams to do dry runs and become accustomed to the system. This is a bad practice that has come into being due to the fact that the client, leadership and sometimes the managers put unfair and immense pressure on engineering teams to start delivering from day 1 or week 1. So the concept of Sprint 0 crept in where these stakeholders are given the confidence that something is happening and the team is buffered from pressure. So what should be done in such cases? It is better to open a dialogue with stakeholders and take time for planning rather than calling it as Sprint 0 which actually goes against the values of Agile and Scrum. Myth 7: Scrum projects are faster to produce output and cheaper to execute Reality: Yes this is true. But only if you are using them in the right environment. If you implement these practices for a wrong project, you can be assured of cost and schedule overrun to happen with a lot of production bugs. For example, you can use Agile and Scrum for mobile App development, but it is not a good fit for Operating system development. Or it can be used for road construction projects, but it cannot be done for Dam construction projects. Myth 8: Sprint backlog is a commitment that has to be honored in all circumstances. Reality: Wrong! Sprint backlog is a collection of work items that you wanted to complete in each sprint, but it is not mandatory to finish it 100%. This means you need not make weekends working or force people to spend long hours in office to complete the sprint backlog. If there is a Sprint backlog remaining at the end of Sprint, then it simply means either the planning was not correct or there were unexpected capacity issues in the team and you need to fix them properly. In such cases, the backlog moves back to Product backlog to be considered in future sprints based on its priority. Don’t bite more than you can chew! Myth 9: Quality can be compromised for faster deployment or shipping. Reality: We all have been seeing this around us; sometimes in our own projects. Yet we choose to look other way and claim that quality was ensured throughout the process. Don’t we notice that these days softwares are having way too many bugs? We brush them aside by saying that software has become really complex these days so this is expected. But in reality, this is a direct outcome of our rush to deliver earlier than we had time to properly make it. Quality should not be compromised in lieu of shipping the product. Always set the KPIs before the start of project and ensure quality measures up to those KPIs [Key Performance Indicators] throughout and especially before shipping the software or product. Myth 10: 0 backlog means Scrum was success Reality: If this was the case then why did that product fail to make any money? Running through the complete list of to-do items and getting a sense of accomplishment is one thing but it does not ensure success unless you made all along the way that you were making the right thing. And that is measured by the concept of value and quality and this is where Scrum Master and Product Owner play the most important roles. So the next time you are going to start a project and want to use Agile and Scrum, step back and analyze the scenario. Ask yourself about the best fit for the project and make sure you don’t fall into these traps of Myths. All the best!  
10 deadly myths of Agile and Scrum
Author Image
Rated /5 based on 20 customer reviews
10 deadly myths of Agile and Scrum

10 deadly myths of Agile and Scrum

Abhinav Gupta
Agile and Scrum have been conquering the minds of engineers, managers especially from software industry quite effectively since last few years. The impact is so much so that every software engineer th...
Continue reading

Value Proposition of Agile Development

Value Proposition of Agile Development The benefits of Agile development have been extolled extensively across the web and almost every one of us is well aware of those benefits. Some of the inquisitive members have taken the efforts to research and study the Agile development framework to understand why those benefits are the products of this framework under discussion. I have no intention of going in that direction since it requires a detailed discussion that is possible in a classroom setting [reach out to your KnowledgeHut support to ask for one].   Through this article, I want to discuss the value propositions of Agile development with you i.e. in essence means, how the benefits of Agile play out for you on the ground during the execution time. What are those actual in-hand benefits that you and your team will reap because of the good thing in Agile development called Value proposition? That is what I want to share with you.   Visibility: The first value proposition that we are going to discuss is “Visibility”. The visibility to the product owner, project sponsors, managers, and engineering team about the current state of the project or product development and whether  we are headed in the right direction or not. Unlike waterfall model, where visibility is highest during requirement gathering phase then suddenly everything goes black and behind curtains with no idea about building the right thing, then suddenly we ship the product with the highest visibility. Alas, that is too late to correct anything if things have gone in the wrong direction. The value brought by Agile in this matter is that visibility remains high at all times; it slightly dips for a week or two during actual development, but it again picks up; so on an average, it remains consistent and at a higher level than waterfall model. This can be easily understood through the means of this graph where the dotted line shows how visibility into the project direction suddenly dips during the execution phase, but it remains constant for Agile.   Adaptability: The word adaptability refers to the ability to accept changes or changing business scenarios and move forward in the new direction with the same vigor and enthusiasm. In any project, adaptability is highest since the project is being kicked off, requirements are being collected so any direction, request or change can be easily accommodated. But things start to change in a traditional waterfall model soon enough and adaptability goes down considerably from the design stage and becomes lowest during shipping. Because once those things are finalized then there is no way to change them without starting all over again. Whereas in the Agile mode, though adaptability remains highest during the initial phase, it continues to hover around the same range through the project duration since every sprint is a chance to pick up something new or change direction as per business need. As you will see in the below diagram, adaptability looks  like this:   Business Value: How your project or product is delivered at the end or at regular intervals, and how it will help the business or your project owner is considered as business value. Because business does not get any value from your project until you deliver something that can be used by end consumers. Needless to say, business value is always available to be consumed at the end of project cycle or rather we should at the time of shipping. The shipping can be at regular intervals [as in the case of Agile] or in the end [as in case of traditional development methods]. In this sense, both Agile and Waterfall sound similar to us but in reality, they are not. Because they vary in the way of delivering business value. Since waterfall believes in shipping in the end or when the product is completely ready, so business value shoots up from 0 to highest suddenly towards the end. That part is obvious. Let us see how it evolves for Agile methodology. Here in Agile, we start delivering incremental versions of the product from the first sprint; so Business value starts getting generated from Sprint 1 and continues to go up until the last sprint or the time when product owner asks us to stop. This is clearly reflected in the graph shown below. Risk This is a remarkably interesting aspect of value proposition for any development model. We all want to avoid risks somehow; sometimes we succeed and sometimes we fail miserably, and our worst nightmares come true at those times. It is not my intention or objective here to dive into many ways to cut risks, but instead, analyze the concept of risk and how it varies according to the development model being followed by the team. It is a common sense that risk is highest in the initial phase of the project since we are dealing with the utmost unknown at that time. Any wrong action or decision by us will lead to failure and a complete wastage of resources. As we progress and start building something, the risk continues to go down and becomes 0 when we ship it. Because either we have succeeded by then or we have failed utterly. Agile allows us to cut down risks faster than the traditional methods because the visibility is maintained at a high level throughout, so if something is going wrong then it is addressed immediately, owing to high adaptability. If we pause and analyze for a while, we understand that high visibility, high adaptability and ability to deliver from early in the game allows us to have minimal risk score through the project rather than working hard for 1 year then finding out that you built something that was not required in first place. That is how Agile development helps us manage risks effectively as long as we execute Agile properly. Conclusion So, as we saw here, any development methodology, related to software field or manufacturing or service-based industry can be analyzed over 4 value proposition parameters, namely: Visibility, Adaptability, Business Value and Risk. In the above post, through means of graphical analysis, we compared Agile development methodology Versus Traditional waterfall and found that Agile development is much better to be followed in recent times with a condition that it has to be executed correctly. You can read my other blog post about “10 deadly myths of Agile and Scrum” whereby I have explained how wrong implementation of Agile and Scrum harms us more than benefit us. With this thought in mind, I take your leave and I hope that next time when you explain to your stakeholders about the need to use Agile, you have a better and stronger story to tell. All the best!
Value Proposition of Agile Development
Author Image
Rated /5 based on 20 customer reviews
Value Proposition of Agile Development

Value Proposition of Agile Development

Abhinav Gupta
Value Proposition of Agile Development The benefits of Agile development have been extolled extensively across the web and almost every one of us is well aware of those benefits. Some of the i...
Continue reading

PMP or Prince 2 – The Management Certification Suitable For You

If you have arrived at this blog and are actually inclined to read it then it is a clear sign that you know what PMP and Prince 2 actually means. And no, it does not refer to the new version of the popular video Game of your college days [Prince]; it is actually the name of the project management certification that has huge followers and fans across the world. And that’s where the trouble starts. For its competitor too, boasts of a huge fan following of its own. The PMP certification, I am talking about. Almost all project management professionals, at least once in their career are in a dilemma about which certification to choose from PMP, Prince2 or ITIL. I, too, was faced with this confusion and finally, I was able to make an informed decision, thanks to the guidance of my experienced mentors and friends. A few days ago, one of my audience at a seminar asked me which certification to choose between PMP and Prince 2 and it reminded me of my days. This caused me to think why not write a blog for general audience and in turn, maybe it will help some of you. So I hope my little attempt serves its purpose. Please do let me know likewise or otherwise by leaving comments below this blog. Let’s begin! Brief summary about PMP – So that you know what we are dealing with: PMP is a trademark certification issued by PMI org and is a world-renowned project management certification that can be practised across domains, industries, and geographies. PMP stands for Project Management Professional and PMI stands for Project Management Institute PMP is governed by a framework known as PMBoK [Project Management Book Of Knowledge] This PMBoK is like a holy grail for PMI members and PMP certified members It gives tools and techniques for different situations and phases of project and it gives freedom to the project manager to decide which one to use in a particular situation depending upon the circumstances, history and future aspects PMP places onus on Integrity, Professionalism, Ethics, Communication, and transparency. PMI guides the project manager on the kind of role he/she should play in the success of projects and this lays down multiple guidance for them to be followed in spirit; the actual implementation may not be a textbook version. Brief Summary about Prince 2 – So that you know what we are comparing against: Prince2 stands for “Projects in Controlled Environment” version2 It also can be utilized for any type of project in the world It clearly lays out the roles and responsibilities of the team members in the project members The project is clearly divided into smaller manageable groups and has well laid out processes to be followed by the project manager It has 3 levels of certification: Foundation, Practitioner, and Professional Practical, to-do format, clear-cut items to be assigned, tracked and delivered are laid out in this AXELOS owned world famous certification. Hence, the name “Projects In Controlled Environment” ☺ As you must have sensed by now, PMP and Prince2 differ from each other in the following ways: PMP deals with a broad-level generic framework that believes in empowering you with the best-in-class tools and techniques but leaves the implementation and decision making to you as per your thought process Prince2 restricts your ability to change things because each and every process is clearly laid out with specific roles for team members and hence, well-defined project success PMP believes that project manager is an enabler whereas Prince2 visualizes project manager as an enforcer. PMP needs to be renewed every 3 years through contribution to the field of project management by sharing your knowledge and learning on your own; whereas Prince2 relies on making you appear for examination every 3-5 years. The terminologies used by each of the certification is different but I think you knew this would happen ☺ Which certification is suitable for you – PMP or Prince 2? We are clear by now, that both certifications are good, both of them are world renowned and both of them can lead to Project success. So which one should you go for? That was the initial question, isn’t it? Well, the answer is very simple and it is not related to the technical superiority of the course material for either of them. It is dependent on facts like: Where you live and work Where your clients are situated The kind of work routine that suits you Yes, strange! But it’s true. It has to come to that. Can you believe that? I couldn’t either when I first got to know about these but it turned out to be true. See, the thing is: Prince2 is followed fervently and much respected in Europe, UK and Australia PMP is adhered to and recommended for certain geographical regions such as North America, South America The remaining world such as Asia and Africa is neutral to both certifications and that leads to the next question: Where are your clients situated? And hence, your home address and your client location determine the certification you should go for. Some often asked questions across different forums:  1) Should I do both the certifications: PMP and Prince? If you can afford them then why not! They are expensive. Around 600-700 USD for PMP and around 400USD for Prince2 [exact price may vary across countries]. So if your pocket allows, then it will be a good thing to have. Is it really necessary? No. I am PMP certified and I have delivered projects to clients across globe and it has not hurt me. 2) Will my pay package increase with these certifications? If yes, which one gives better yields? Yes, your package will go up substantially after getting certified because it signifies that you have spent effort in getting familiar with the best-in-class frameworks and techniques. So big clients and companies can rely on you. The positive increase is almost similar for you. 3) Which certification is better for Infrastructure projects? Are they specific to IT or software projects only? No, they are not specific to IT or software projects. Yes, they can be used for Infrastructure, manufacturing or service-based projects. Because both the certifications allow you to learn the best techniques to deliver a project. The only difference is in the way they approach success. While PMP believes that you can do well as long as you know the right way of doing things, Prince2 believes in making sure that you follow the right path. 4) Is there any gender-specific preference in the certifications for PMP or Prince2? No. 5) If I have clients in the Middle East and Asia, which one should I choose because you just now mentioned that these regions are neutral in terms of preference for project management certifications. Going by historical data, Arab world has better connect with Europe and in recent times, some countries have developed good business relationships with America. So depending on the client and your profile, you can choose either of them. However, if you are looking for a safer option and a long-term career in the Middle East, then I recommend that you take both certifications- PMP and Prince 2. I hope this post was useful to you. By the way, do not forget that KnowledgeHut is a certified recognized provider of training for both the certifications: PMP and Prince2 with a very high success rate. All the best! ☺  
PMP or Prince 2 – The Management Certification Suitable For You
Author Image
Rated /5 based on 20 customer reviews
PMP or Prince 2 – The Management Certification Suitable For You

PMP or Prince 2 – The Management Certification Suitable For You

Abhinav Gupta
If you have arrived at this blog and are actually inclined to read it then it is a clear sign that you know what PMP and Prince 2 actually means. And no, it does not refer to the new version of the po...
Continue reading

Guiding Principles of Agile and Scrum

  “Guiding Principles” are the set of values and propositions that form the foundation of any principle, theory, framework or business. They outline those principles that were responsible for a particular framework or business to come into being because the creator(s) wanted to make sure these principles were being implemented and kept in mind by the followers, practitioners or future leaders. Guiding principles exist and are necessary for every great and useful idea that ever existed. In this post, I want to share with you the guiding principles that were the source of creation for Scrum and Agile. While the guiding principles for them were issued by two different groups trying to solve two different problems that existed in the engineering world, their thoughts converged at the same point. And that is where I intend to pick up the thread from. So that, you as a reader get to know what exactly Scrum alliance and Agile Manifesto team wanted us [The engineers, managers, product owners etc.] to follow from its soul even though our implementation in execution might differ from project to project. With this thought in mind, I present to you the Guiding Principles of Scrum and Agile. Guiding Principles of Scrum: 1) Courage: Surprised? I can understand if you are. You might have expected something more technical as a guiding principle and here it sounds like some armed forces training manual! Here there is no twist in the definition of “Courage”. It remains same as the one outlined in Oxford dictionary. Courage is the willingness to take on a difficult seemingly impossible challenge and commit to oneself about its completion towards success. As a Scrum team, taking on a journey to deliver a product or solution has the fearlessness to take on something that has not been solved yet needs “courage”.  2) Focus: The Scrum team has to remain focused on the end goal they have set out to achieve. Never during their journey are they supposed to waver from that goal.  No amount of technical discussions, blockers, challenges etc. will be able to deviate the Scrum team from its goal. 3) Commitment: Scrum teams promise to deliver and adhere to the goal they have set out to achieve. No matter what the challenge or technical blockers that might come; the team will ensure they deliver what they have promised. The team will always make sure that they deliver what they have promised. This where Courage, Focus, and commitment converge. The team will be brave enough to promise to deliver what has not been attempted so far and will be unwavering in its approach to deliver what has been promised. 4) Respect: Mutual respect is a very important pillar of any team and no great thing was ever achieved until the team members had mutual respect for each other. Since Scrum team has already set out to achieve the unimaginable, mutual respect gains all the more importance in the given scenario. How can a team achieve something great if team members do not get along well and trust each other to deliver their assigned tasks to the best of their abilities? Hence, mutual respect for each other’s capabilities, expertise and shortcomings is an essential part of the Scrum team. 5) Openness:Ask yourself, what is the importance of free, fair and open communication between the team members of a team that wants to achieve the unthinkable with complete focus on delivering the commitment and that too without any official or full-time leader to guide them? You would have gotten the answer yourself by now! ☺ So this is what Scrum alliance had in mind when they created the idea of Scrum teams for the first time. Now, let us review the Agile Manifesto and then let’s tie them together into a meaningful picture for us to guide us throughout our project execution. <iframe width="560" height="315" src="https://www.youtube.com/embed/tQprHSpNdps" frameborder="0" gesture="media" allow="encrypted-media" allowfullscreen></iframe> The Agile Manifesto in my own words The  Agile team will always ensure and strive to satisfy its customers [whether internal or external] through early and continuous delivery of valuable work i.e. every Sprint will deliver something of value to the customer. Break big work down into smaller components and hence, Agile team will ensure success by conquering small and continuous pieces of puzzle. An Agile team will recognize that the best work emerges if the team is self-organizing i.e. the team will proactively take responsibility and act to solve the problems and deliver value without any need for formal guidance at all times. The product owners and sponsors will provide the motivated Agile team with all the requirements, environment and support as needed. The product owners will not constantly interfere with the team’s functioning but will always trust them to get the job done. The Agile team will create processes that will enable the team to work in the form of sustainable efforts. Agile teams will ensure that they maintain a reasonable and constant velocity towards their end goals without putting extra pressure on resources. The reasonable velocity ensures sustainable growth and provides good amount of visibility to project owners for forecasting. Agile team will never say no to changing requirements and will accommodate them even late in the game. The Agile team and its business owners will meet together on daily basis for not more than a quick check of their progress towards the end goal by measuring the value delivered till last night. The meeting came to be known as Scrum meeting when Scrum became the most preferred way to implement Agile. At regular intervals the team will meet to review the mistakes committed along the way and fix them so as to not repeat them again. This came to be knowns as Sprint retrospective. The Agile team will be careful to not confuse velocity with Value and will measure the daily progress towards the committed goal with value generated till date. The Agile team will continue to drive itself to improve towards excellence. The Agile team will be open to the upcoming changes in business scenarios, technologies and evolving thought process for competitive advantage. How these guiding principles should lead us to success If we spend some time with ourselves and think about the guiding principles that we just now discussed then we see an evolving pattern here. Any team that vows to become an Agile team aiming to deliver excellent products in an iterative fashion using Scrum as its execution tool should have their basic morals right in the place in form of commitment, focus, respect and openness to accept each other. That team should have willingness to improve, to learn from its mistakes, always keep its customer in the sight and knowing that it is the customer they are out to serve, so accepting changes is a part of their program. This is a team that also smartly understands the need to continuously deliver value on a regular basis but at the same time ensures and plans in a way to maintain harmonious balance between work and other aspects of life through reasonable sustainable velocity and supporting processes to help deliver. With these words of interpretation, I hereby invite you to rethink your Agile execution in project and wish you all the best for a better life, better products and better relationships. All the best!  
Guiding Principles of Agile and Scrum
Author Image
Rated /5 based on 20 customer reviews
Guiding Principles of Agile and Scrum

Guiding Principles of Agile and Scrum

Abhinav Gupta
  “Guiding Principles” are the set of values and propositions that form the foundation of any principle, theory, framework or business. They outline those principles that were r...
Continue reading

How To Generate Requirements From Use Cases

In earlier posts, I wrote about user stories that can help capture user’s requirements holistically and encompass the needs of your customers; I also wrote that user stories should then lead to use cases enabling your engineering team to get something concrete on paper for building. This is the third and final post in this series: How to generate requirements from use cases. The simplicity of this task can be misleading. If we, as project managers or product managers, fail to accurately translate our refined and well understood user stories, use cases into requirements; then our engineering team is doomed for failure. Why? Because requirements that were being tracked to completion before shipping were not completely and correctly comprehended, in spite of having good user stories and use cases. Hence, it is very simple but an important step where you should get final requirements correct down to the last detail. I could have used the term “write” or “create” requirements from use cases; like I did for my post of Use cases but I chose to use the term “generate”. Why?  Because your product or feature requirements should organically arise out of use cases and you only need to start the documentation process to have them recorded; assuming you have done your job correctly. Before proceeding, I humbly request you to please read and understand earlier two posts on “how to work with user stories” and “Use Cases - How they are different from user stories and how to create them”. And feel free to raise questions to me by replying to the comments or emailing me directly. Now, assuming that you have read those two articles; let us begin on the last stretch of this journey. What are requirements? Please take 30 seconds and try to put in words; what is meant by the term “requirements”? Time yourself! I am waiting. Tough! Isn’t it? Exactly! Because while we all intrinsically know what requirements mean, we are not able to put them into words and whatever can’t be put into words, can’t be explained to the audience. Unless we have a way to put our requirements into words exactly the way we understand them intrinsically, we will not succeed in our goals. To begin with, I define requirements as a clear concise sentence of not more than 10 words specifying the most singular unit of demand. A simple example of generating requirements from use cases: Let’s continue with the same toothpaste development example from my use cases post so that we all are on same page and mutual mental understanding remains. There we had developed a user story for John, our user, who wanted to feel fresh and energized even after 12-14 Hrs. of work day. And based on that, we had developed some use cases; remember? See the post here. Listing some use cases again here for ease. Use case 1: User wants to have a premium quality feel when he/she takes the toothpaste tube in hand before brushing. Use case 2: User gently squeezes the tube and he is pleased with the smoothness of the paste flow out of this tube. Use case 3: User is able to notice the right amount of paste coming out of the tube every time, he/she brushes. It is never too much nor too little. One gentle squeeze always gives out the right amount of paste required for brushing. Now let us generate requirements out of those. Always remember, following things while generating requirements: Requirements should be concise and should contain only one demand in them. A single use case should not be giving rise to more than 2, at max 3, requirements. If a use case is able to generate more than 3 requirements then it is a clear sign that this use case is in fact a half-baked user story and needs to be broken down further. If a requirement cannot be expressed in less than 10 words then it is a use case in disguise and you need to relook at your user stories once again All requirements should have priority. We will be using tabular format so that we can maintain requirement traceability. 1) Requirement number has to be unique and will be used to track the requirement in various forums, discussions and work breakdown structures. Recommended format for requirement number is X.Y where X refers to the use case number and Y refers to the unique requirement within that use case. For example: 1.1, 1.2, 1.3 and so on to depict 1, 2, 3 requirements for use case 1. 2) Requirement description as we know is a clear concise sentence of less than 10 words depicting a single unit of demand 3) Use case generated from allows the product manager and engineering team to know which use case generated this particular requirement and suppose, down the line if use case or user story undergoes modification then we will clearly know which requirements are impacted and require a review. So it helps in that sense. 4) Business priority is not to be confused with task priority. Every task that is a child of a requirement will have its’ priority depicting the order in which they should be done. So, let us generate requirements for Use Case 1: “User wants to have a premium quality feel when he/she takes the toothpaste tube in their hand before brushing.” Now, let us generate requirements for Use Case 2: User gently squeezes the tube and he is pleased with the smoothness of the paste flow out of this tube. Now, let us generate requirements for Use case 3: User is able to notice the right amount of paste coming out of the tube every time, he/she brushes. It is never too much nor too little. One gentle squeeze always gives out the right amount of paste required for brushing. And so on you can develop your requirements. I hope you enjoyed this post as much as I did! ☺ All the best!  
How To Generate Requirements From Use Cases
Author Image
Rated /5 based on 20 customer reviews
How To Generate Requirements From Use Cases

How To Generate Requirements From Use Cases

Abhinav Gupta
In earlier posts, I wrote about user stories that can help capture user’s requirements holistically and encompass the needs of your customers; I also wrote that user stories should then lead to ...
Continue reading

ITIL Practitioner: Importance of “Adopt and Adapt” Principle and SWOT analysis

In my previous posts on ITIL Practitioner, we walked the journey of basics of ITIL practitioner, then emboldened by our little endeavor, we explored core competencies of ITIL, 9 guiding principles and tried to understand why “service strategy” is the core of ITIL framework. Briefly, we had touched upon the concept of Adopt and Adapt that is the core message of ITIL framework governing body. In this post, I will share my thoughts with you on how ITIL’s core concept of “Adopt and Adapt” is part of their curriculum and if possible, I will share some examples with you. What is Adopt and Adapt concept? Adopt says take whatever you like and think will be useful for your project or organization. Adapt says change it to suit your needs. Simple! Not so. Because this simple looking definition is full of pitfalls and very dangerous ones, at that. If you start adopting everything that you liked in other projects and companies then soon your own project and company will be overburdened with things that do not work well together and worst still, there will be humongous redundancy in techniques and tasks. Let us take a simple example of internet search engine. Suppose I am the owner of company XYZ and I am marketing a new internet search engine service known as XYZ-Search. While my engineers and managers are working hard to make sure that my internet search service performs well on the parameters that have been given to them; at the same time, I should also be spending time to find out the existing best practices being followed by my competitors and peers. But I exercise extreme restraint before actually taking those practices and asking my engineers to follow them blindly. For example, it will be foolish on my part to build a sprawling campus with 24*7 entertainment facilities for my engineering team working on XYZ-Search just because Google does it for its employees. No doubt, this kind of environment does have its own benefits, but it comes with its own cost. And being a start-up, my XYZ-Search cannot afford this. So in spite of success for this organizational facilities, I should not be adopting it as-is. Similarly, I notice Google search engine places online advertisements on specific locations on the page such as top, bottom, right navigation panel etc. So if I tell my engineers, UX, and marketing team to start putting such advertisements on my XYZ-Search page then I can easily drop my dreams of tasting success. Why? Because Google is earning those advertisements on the basis of top-class search results that lead to user satisfaction and if I try to replicate that financial model for my XYZ-Search engine service then it will be thrown to trash in a matter of a few days. Always remember, bad quality never goes unpunished!  But I do want to adopt my peers’ success model; so what should I do? In that case, you need to learn to adapt. The concept of adapting means that you tailor the existing product or service as per your needs and requirements that suit you best. We know, this is a required thing to be done else it leads to the problem of force fitting leading to a lot of other issues such as employee dissatisfaction, customer drain, regulatory non-compliances etc. To continue with our example of internet search engine service, if our very successful competitor, Google, decides to set up a 24*7 customer care number that provides personalized attention to each caller, then obviously, this initiative is going to win a lot of appreciation from the clients for Google. Who does not want a personalized support and care in business especially if things are not working as expected? But it would be foolish on our part to adopt this model in its entirety; in fact even suicidal for our startup that is already tight on cash inflow and is in primitive stages of internet search engine service development and release. So how do we adapt here?  Because adopting this wonderful idea is a no-brainer; it would be stupid to not implement this. But how to make it fit for us? That is where your SWOT analysis comes into picture. SWOT stands for strengths, weakness, opportunities and threats. How will this help us fulfill our needs? Let’s see.  SWOT analysis to Adapt the Adopted SWOT analysis is helpful here because it will help us nail down the reasons why we want to adopt a best practice, what are our current challenges to be solved through this, what are the constraints that limit our ability to go beyond what is currently possible and what benefits we are going to reap if we are successful. Let me show you an example of this internet search engine service 24*7 customer care with personalized attention. What are our Strengths? Here we or anyone is supposed to list down the aspects that are your strong points for a given situation. You will need to involve more than 3 but less than 10 people in this exercise to get some tangible outcomes. Let’s give it a try. 1) We are a startup with limited and very minuscule customer base; since we are just starting up In normal circumstances, this would be considered as our weakness but in this case, this is our strength; see how This implies that the demand to set up 24*7 customer support is almost nil or maybe does not even exist. And that actually cuts down on our cost factor to set this up 2) Our another strength is, in this case, that no one expects us to give a wonderful customer support since we are a startup busy with getting our service correct first. So the pressure to set this up is not there. What are our weaknesses? Here, we list down our weaknesses in this area. 1) We do not have big purse or deep pockets; that means we cannot spend money on getting state of art technical automated customer support setup 2) Our developers are busy in developing next version, and they barely have time to work with customers for live site issues And we do not have the capacity to hire new developers What are the Opportunities? List down the scope of getting ahead in business and on your competitors, if you succeed in this case 1) Since the expectations are low, so if we are able to provide 24*7 customer support with personal attention then it takes our customer ratings higher at a very steep rate. This positive feedback loop in turn would lead us to get more business and hence, bigger market share Wow; didn’t think it that way! 2) Customer feedback loop would allow us to develop features that are more relevant to them and since our customer base is small, the impact of positive reaction would be higher Hence, more business through positive word of mouth What are our threats? Here we list down the threats that might hamper us on this journey or worst still, the losses that we may incur if we fail. 1) The much-needed finance would be diverted for something that was not asked for in the first place. 2) We are opening up another input channel for our engineering team through customer feedback and not to forget, our engineering team is already overloaded 3) Increased business might become a bane for us if we don’t keep up with the same quality of customer care going forward, and we might lose business due to that. Now, our SWOT analysis is done; and what is the result? That depends upon you and your risk appetite. Now, you should have a discussion with your team and managers and stakeholders and arrive at the best way to go forward depending upon the above SWOT analysis. And before you realize, you will have a perfectly adapted version of a best practice in your hands for your benefit! ☺ All the best! By the way, if I were you, I would have chosen to implement this model of personalized attention to all customers but only during specific hours of the day along with specific modifications to engage with other countries’ customers.    
ITIL Practitioner: Importance of “Adopt and Adapt” Principle and SWOT analysis
Author Image
Rated /5 based on 20 customer reviews
ITIL Practitioner: Importance of “Adopt and Adapt” Principle and SWOT analysis

ITIL Practitioner: Importance of “Adopt and Adapt” Principle and SWOT analysis

Abhinav Gupta
In my previous posts on ITIL Practitioner, we walked the journey of basics of ITIL practitioner, then emboldened by our little endeavor, we explored core competencies of ITIL, 9 guiding principles and...
Continue reading

ITIL Practitioner: Core Competencies, Guiding Principles and Service Strategy Importance

In my previous post, I wrote a beginners article for ITIL practitioner. There I spoke about how ITIL practitioner certification fits in the entire ITIL framework, we briefly touched upon the examination format for ITIL practitioner course, I wrote about what benefits you and your company can have if you choose to take ITIL practitioner certification and most importantly, I tried to answer the question, “whether you should choose to go for ITIL practitioner certification or not”. Now, in this post, I will try to delve a bit deeper into the other but very important aspects of ITIL practitioner course and those are following: What are the core competencies of ITIL Practitioner Various guiding principles of ITIL Practitioner And to answer the question of the previous post- “Why service strategy is considered the core of ITIL and ITSM framework” Let’s start! Core competencies of ITIL Practitioner: Core competencies refer to the major engine behind ITIL framework. All the processes, steps, functions and techniques revolve around these competencies in the ITIL universe. These three core competencies are as follows: Critical competency Guiding Approach CSI or Continual Service Improvement Critical Competency talks about the critical requirements that any member or professional or organization should possess if they want to achieve success in their service-based projects. Those competencies have been categorized into 3 sections: Communication Organizational change management Measurement and Metric I personally, like to refer to them as CMO [for the ease of memorization]. As expected, communication refers to the paradigm where every individual in your team/project is able to articulate his/her needs, wants, requests in a clear concise manner and as well as to be able to decipher the sender’s message in its accurate form of meaning. Not only this, it also covers the area where the project manager or the project owner needs to ensure that communications to all stakeholders, customers, internal or external are handled properly, documented for future reference and lead to overall service satisfaction. Measure and Metrics deals with the obvious concept that what you can’t measure, you can’t improve. Hence, you will not be able to gauge with accuracy if your service is providing the benefits or not, if your project is on track or not or if the service that is eating resources is performing its intended job or not. For example, an internet search engine service might be able to return more than 1000 results for the most basic of queries. But whether those results are relevant to the user or not will decide the fate of your internet search engine company. In the above case, the internet search engine service is doing the job well by returning more than 1000 results to choose, but if none of those results are the ones user is looking for then it is a failure. And you will not be able to know if you can’t measure effectiveness, efficiency, user satisfaction etc. Hence, measurement on the scale of defined metrics is very important competency to have in ITIL. Organization change management depicts an organizational structure that deals with change management for the service you are providing. Let us continue with the example of Internet search engine service.  Once you could identify, through Measurement and Metrics, that your service was not returning relevant results for your users, then obviously you will engage your engineering team to work on the improved service design. New service design will require changes in the existing search engine code, infrastructure and may be configurations as well. Not all changes, can be, should be and will be approved. Right? We all know that. So there needs to be a change management board for your organization [or project] that will discuss the merits and demerits of all the proposed changes, prioritize them as per business benefits and costs involved, then finally give go-ahead or not. This is what organizational change management is all about. No service management project or organization can succeed if they do not have these 3 competencies sorted out perfectly. And that is where your role as an ITIL practitioner becomes important. Guiding Principles of ITIL Practitioner Now since your project and organization has entrusted you to get the service management perfect and set the core competencies in place and get the parts moving, being a thorough professional and an ITIL practitioner, you will do those perfectly well. Because you have the knowledge required to do this. But what should be your guiding principles for the situations that are not mentioned in the ITIL practitioner guide, what should decide your way forward when you will encounter roadblocks resisting change, and what values should you believe in before you explain the needs of these improvements to stakeholders. And those mantras to guide you in difficult, uncertain, moralistic situations are known as “Nine Guiding principles of ITIL Practitioner”. I personally believe that even if you lose your ITIL practitioner guide [which I hope you don’t because it is not cheap] or if you forget the technical knowledge, as long as your guiding principles are correct you will never falter on your journey. Those principles are as follows: Focus on Value: Always try to look beyond materialistic gains. Look for long-term value. Will it help the organization in long run? Will it solve some genuine problems? Will your customers/users thank you for it? Design for experience: Always ask your designer to keep themselves in the user’s shoes and try to use the service as if they were them. Then check if this current service is being helpful to them or not. This actually helps eliminate a lot of faux pas that actually look good in presentation but are miserable failures when released to the market. Start where you are: There could be multiple interpretations to this statement, but in simple terms, it states, do not forget who you are, where you come from and what your current ground reality is. If you are clear about these things, then more often than not, you will make correct plans. Work Holistically: Always remember, your work and your service not only help solve a problem, but it interacts with a lot of other components in the ecosystem also whether technical, mechanical, and emotional or culturally. So work holistically. An internet search engine may provide accurate results, but in a country where those results are banned or are offending the audience’s religious faith can seriously backfire on you and your organization. Progress Iteratively: Always break the problem into smaller pieces and achieve one or two steps at a time. This helps you get user feedback and improve your service at a low cost, rather than creating the whole service and finding out that there is no market for it. Observe directly: What if you rely on sources to get you the feedback or user reactions or problems data and later on find out that the “source” did not understand the feedback properly, leading you to make something that was not required at all. Or worst, the “source” had vested interest and now your service is out of the market. So don’t take the risk. Focus more on getting the data directly. Be Transparent: Good or bad, whatever be the situation, it should be clearly communicated to your stakeholders. All the decisions along with their rationale should be explained to the audience. Precaution should be taken to not divulge unintended information to the unintended audience. Still, there should be transparency. For example, you got a feedback that in the Middle East your service was gaining negative publicity due to the search results being rendered on a particular topic in spite of the government directive against doing so. In such cases, you are expected to inform your stakeholders about the situation, your plan to tackle it and to inform the end user about the upcoming change. You need to explain the exact problem and its implication to the business users, but you need not maintain the same detailing while sending out communication to market users. So use your filtering mechanism but ensure that transparency is maintained. Collaborate: Not everybody has answer or solution to everything. So better to get best people for their competencies and sometimes, more minds can give you better results. So mix and collaborate. Simple! Keep it simple: Means keep things simple and do not overcomplicate them for showing proficiency. And finally, continually improving service talks about the goal where you have to keep finding ways to improve your service through measure and metrics via communication and organizational change management. So these are the 3 competencies of an ITIL practitioner along with their 9 guiding principles- Why is service strategy the core of ITIL Practitioner? You will be amazed by the answer! It keeps in line with the 9th guiding principle of ITIL. And that principle was: Keep it simple! And this is the reason, I did not answer this question up until now. The answer is: Service strategy deals with the knowledge of what service are you [as a company] going to create through this project and why. It talks about the plans to be executed to develop this service, how to market it, how to provision it, what business benefits will it drive for users and for the organization. So once you have that clear, all your plans, processes, techniques need to be modified to align with that goal, else there is no point of creating an internet search engine service that gives wrong results to the user even if it works very fast.  And this is the reason why Service strategy is the core of ITIL practitioner. Because you need to make it clear to the team you are going to work with!  
ITIL Practitioner: Core Competencies, Guiding Principles and Service Strategy Importance
Author Image
Rated /5 based on 20 customer reviews
ITIL Practitioner: Core Competencies, Guiding Principles and Service Strategy Importance

ITIL Practitioner: Core Competencies, Guiding Principles and Service Strategy Importance

Abhinav Gupta
In my previous post, I wrote a beginners article for ITIL practitioner. There I spoke about how ITIL practitioner certification fits in the entire ITIL framework, we briefly touched upon the examinati...
Continue reading

Project Management Professional [PMP]: What’s new in 6.0?

Project Management Professional certification, popularly known as PMP certification, is an internationally recognized certification introduced by Project Management institute [PMI] in 1996 as version 1.0   This world recognized, multi-industry approved, cross-functional and much respected certification is currently in its 5th version with 6 updated version announced on 6th  September, 2017 by PMI.   From 2018, PMP certification will be following the guidance issued by PMI in PMBOK® - 6.0th Edition.   PMBoK stands for Project Management Book of Knowledge and can easily be considered as Holy Book for Project Management Professionals. This books defines, discusses and lays down all the project management principles to be followed by professionals throughout the project from initiation to closure.   This post is about discussing the new introductions and changes in the PMP certification and hence in PMBOK® - 6.0th Edition. It goes without saying that this post assumes you are already well-versed in the history of PMP, PMI, knowledge areas, Process groups and most probably, you are already certified or in the process of getting PMP Certified.   Later, I will write some more on the other topics based on your feedback; but for now, let us discuss PMP 6.0 i.e. PMBOK® - 6.0th Edition changes as announced by PMI on 6th September, 2017.   Why the changes are required in PMP certification or PMBoK?   Since its introduction in 1996, PMP has undergone 5 revisions and this is the sixth one. This revision happens every 3 to 4 years as shown below.  1996, PMBOK® - 1st Edition 2000, PMBOK® - 2nd Edition 2004, PMBOK® - 3rd Edition 2009, PMBOK® - 4th Edition 2013, PMBOK® - 5th Edition  As you can see, there is a method to the madness [as I love to call it]. The revision happen regularly every 4 years. This is because PMI is a distinguished member of ANSI [American National Standards Institute] organization; and this membership requires PMI to update its guidance and book of knowledge every 3 to 5 years. Hence this explains the frequency of updates. Generally what kind of updates come in revisions?   PMP certification and project management Book of Knowledge is not restricted to any specific industry or domain. It lays down the best of practices that are certified by Industries, organization to be the most optimum practices for efficient project management.   You can take any industry; be it Manufacturing, or service; all these best practices apply to all companies uniformly. Hence, PMP certified professionals are in great demand across the globe for their knowledge and ability to work across domains, factories, industries and geographies, due to their usage of uniformly approved terminologies and processes.   In every revision, PMI comes up with learning from latest advances in technology across sectors, updates in governance policies introduced by ruling authorities, updates in the best practices based on the results of last few years and introduction of new concepts that have a potential to be big game changers in project management.   Hence, the updates can be categorized in following manner:   1) New learnings and processes introduced in recent times   2) Updates to best practices based on the results of last few years   3) Updates in processes based on recommendations from standard and authorized bodies across the world   4) Game changer items that are going to be critical in project management.   What are the changes in PMP 6.0 or PMBOK® - 6.0th Edition?   Change # 1: AGILE is now officially part of PMBOK® - 6.0th Edition  AGILE has been creating ripples  across the industries and projects for quite a few years now. PMI has recognized the trend and its potential to transform the way projects of future are going to be managed. There is going to be a dedicated booklet for AGILE, being shipped along with PMBOK® - 6.0th Edition  Change # 2: PMI Talent Triangle   PMI defines talent triangle as trinity of principles to achieve success in the project  As the name hints, it consists of 3 processes Process, People and Technology and how they can be combined together to achieve success PMI discusses this concept in details in the 6th version  Change # 3: Process groups are now 49 processes instead of 47  “Manage project knowledge” has been introduced to define how the knowledge accrued in Project execution can be managed “Control resources” has been introduced to control the resources. Note the usage of word control instead of manage “Implement risk responses” has been introduced as a separate process to manage the responses received during risk analysis. Earlier this was an activity; but now it is a full-grown process in itself owing to increasing uncertainties of projects in current times. “Close procurements” has been deleted. This was a separate process earlier but no more.  Change # 4: Renamed multiple process to reflect the current situation of project management  “Project Human Resource Management” has been renamed to “Project Resource Management”, because resources can also include non-human resources such as electronic devices, software, infrastructure and logistics. “Project Time Management” renamed to “Project Schedule Management” because  schedule management needs to consider constraints on resources, risks, material and time. Hence the word “schedule” is more apt than “time”. “Perform Quality Assurance” changed to “Manage Quality” to reflect the development in thinking that Quality assurance is not a simple activity that you can perform in one go. Quality assurance in an independent career in itself. So this should be managed. “Plan Human resource management” changed to “Plan resource management” is self-explanatory because resources need not be only human. “Acquire project team” has been renamed to “Acquire Resources” “Control Communications” is now “Monitor Communications” to indicate the relaxation,and is debatable because here it takes out the onus of controlling the communications from Project manager and puts it on the team to conduct their communications in a responsible manner. “Control Risks” has been renamed to “Monitor Risks”, because managing risk response has been created as a new process. “Plan Stakeholder Management” is now “Plan Stakeholder Engagement”. Every good project manager knows that stakeholders need to be engaged with at multiple levels rather than simply managing them through reports and status meetings.  “Control Stakeholder Engagement” to “Monitor Stakeholder Engagement” to reflect change in the notion that project management should monitor such engagement rather than being heads-down in controlling them. Change # 5: Role of project manager in a project gets a chapter for itself   This time, PMI spends a chapter on the topic of the role and responsibilities of project   manager as a whole. This is a big deviation from the old times, where PMBoK considered Project manager as a whole sole owner of project. But this time, PMI has expanded the definition of project manager and given him/her a broader role of a guide, mentor and monitor. Change # 6: Distinctions between most commonly mistaken terminologies such as:   On-Going and Non-Ongoing processes  Project Scope and how it is different from product scope  Communication and communication(s) Change # 7: Introduction of Risk response escalation strategy Here it discusses how to escalate the risk and its corresponding actions to the concerned stakeholders and multiple ways to handle this.  So these are 7 major changes in PMP certification and PMBOK® - 6.0th Edition; all of these changes will come into effect in the first quarter of 2018.   If you are planning to get certified before December, 2017 then continue to refer to PMBoK ® Version 5, else start referring to version 6.   In short, I can easily see that PMI has defined the role of Project manager to be more of a guide, allowing greater independence to the execution teams and at the same time, it assigns the tasks of responsible, correct communications, managing the risks to the team rather than only on PMs.   PM, in turn, has to coach the team to identify and plug the holes in their executions, plans and strategies.   The new version of PMBoK is definitely a step towards better and cohesive coordination between project management team and execution team, ensuring success through optimal usage of technology i.e. PMI Talent triangle!   All the best!   Feel free to write to me for questions and clarifications.  
Project Management Professional [PMP]: What’s new in 6.0?
Author Image
Rated /5 based on 20 customer reviews
Project Management Professional [PMP]: What’s new in 6.0?

Project Management Professional [PMP]: What’s new in 6.0?

Abhinav Gupta
Project Management Professional certification, popularly known as PMP certification, is an internationally recognized certification introduced by Project Management institute [PMI] in 1996 as version ...
Continue reading

Use Cases: How Are They Different From User Stories & How To Create Them

I could have used the word, “write” instead of “create” use cases. But I didn’t. If you know why, then you are already expert on this topic, so please do share your opinion and knowledge by adding some comments at the end of this article. If you don’t know why I consciously mentioned “create” instead of “write” then worry not. I will share my thoughts  with you and you can tell me what you think and let’s create a dialogue around it. In my previous article, I had written about user stories, and how they came into extensive usage, how they help develop better products and how they represent users’ voice at forums users don’t have access to. If you have not read that article then I would sincerely request you to read that article first as it will immensely help you in getting the right perspective about this topic at hand. Use cases in simple words are exact statements written in informal manner depicting the specific action that the user is expected to do while dealing with a particular functionality of the product. If you compare this with the definition of user stories I gave in my previous article, you will notice that here I have defined use cases as “exact statements” whereas I had defined user stories as “generic statements” written in informal manner. Why? This is because user stories set a foundation upon which great use cases are created or developed. While user stories try to explain to the engineering team about the environment, goal, role, intention of the user while he/she is going to deal or work with the software; use cases clearly define what the user is going to do here and what result is expected in crisp 2-3 lines. Use cases are one level above requirements. Below is a simple table for quick reference on differences between user stories and use cases. A simple example of creating use cases from user stories: Let us take a very simple example of a toothpaste and let’s create use cases out of it. If you want to see how to develop user story then please read my earlier article on user stories. Always remember, while it will seem easy to create use cases directly from user needs; it is full of pitfalls that might lead to missed functionality and user dissatisfaction later on, after shipping the product. So a user story would look somewhat like this: Actor  :    John, a working professional who wants to keep his teeth health and shiny Role    :    The direct consumer of this product but can influence others by his reviews of a product on his website. Expected results: After brush, John expects his breath to be fresh and teeth and gums to be health for the whole day. Now as you can see, John is a very high impact user for us [The toothpaste company] because he can affect our sales by his review of our product on his website. So meeting his needs are very critical for us. Hence the product manager, should create following user story for this scenario. Sample User Story: It is 6:30AM in the morning and John has started his morning rituals to be ready for work. Daily, his first routine after waking up is to brush his teeth with his favorite toothbrush so that he gets the refreshing feel to do remaining chores around the house and leave for work on time. He likes the way toothpaste, smoothly oozes out of the tube and rests firmly on this toothbrush without spilling anywhere. Also he likes that somehow, every time he brushes, the exact right amount of the paste comes out of the tube. It is never too much and never too little. It’s just right. He feels energized after a refreshing brush ritual and likes the feeling of freshness in his mouth after brushing his teeth. His gums feel rejuvenated, breath feels fresh as he tests it out on his palms. After spending whole day at office, where he had multiple cups of coffee, some food and some sugary items, he comes back home. While refreshing himself, he notices that his breath is still fresh and the taste in his mouth is still neutral without any traces of coffee or cheese pizza he had before. He is so pleased with the product that he has bought for himself, that he decides to write about it in his blog tonight. Now let us create some use cases out of the above user story. Use case 1: User wants to have a premium quality feel when he/she takes the toothpaste tube in their hand before brushing. Use case 2: User gently squeezes the tube and he is pleased with the smoothness of the paste flow out of this tube. Use case 3: User is able to notice the right amount of paste coming out of the tube every time, he/she brushes. It is never too much nor too little. One gentle squeeze always gives out the right amount of paste required for brushing. Use case 4: User feels an air of freshness in his mouth after brushing and that freshness lasts for minimum of 24 hours. The feeling of freshness is neither overwhelming nor un-noticeable. It is just mild   enough to provide a feeling of freshness while not interfering with user’s culinary habits. Use case 5: The user is pleased with the fact that the teeth and gums feel very smooth and non-scratchy after every brush. Use case 6: User is happy about the fact that even after 12 hours of intense work day routine, his breath still feels fresh And so on and so forth.  Can you think of some more use cases? If yes, do leave your comment below so that we can discuss on their validity and applicability here. Is the concept of use cases starting to make itself clear to you now and how they are different from user stories? Let us try once more. This time let us try to create use cases of this same product but for different customer base. Sample 2 of creating use cases for a product: This time, instead of a working professional, John. Let us consider Alayah, a teenage girl in high school. Actor :    Alayah, a 16 year high school student who is interested in experimenting new things with regards to body hygiene for better well-being and feeling. Her opinion is slightly influenced by the           feedback of her friends and her own personal experiences as she too likes to share her feedback with them. Role :    A direct consumer of our product and her feedback can motivate others in her circle of influence to try out our product. Expected Results: While healthy teeth and gum are the most basic of her requirements, she is bored with the same tasting toothpastes on offer these days. She wants to try out a new toothpaste that     not only provides her with best dental protection but also convinces her Mom of her ability to choose different but a better product by herself. Here, our engineering team’s task is clear. They need to create a product [toothpaste in this case], that not only impresses Alayah but also provides her with the best dental protection that she needs at her age. Her feedback carries the possibility of our product’s adoption by her immediate family members and her close friends, hence opening the market for us. The product should be unique in itself while being the best in terms of quality at cost effective price, since Alayah is not an earning member of her family. A product manager in this case, will have lot of options to think of a product here and specify to the engineering team. Let us go with one of them. Do share your versions of user stories in this case. User story: It’s morning time and Alayah’s alarm is ringing she had set last night to wake her up on time, if she needs to make it to the school without being reprimanded. She quickly jumps into the shower with a toothbrush having toothpaste on it, while her favorite song is playing out on her personal stereo. While she is freshening up, she is delighted with the fact, even after so many days, her toothpaste continues to give out the same wonderful strawberry flavor that she loves so much. And to add to her delight, her dentist gave her a big thumbs up yesterday on her teeth and gum health. Alayah has been using this toothpaste for a month now and she loves the way, the tube feels like new everyday even after so many uses. She never has to squeeze hard to get the paste out of it. One gentle squeeze and strawberry colored toothpaste gently but firmly oozes out of the tube and rests on the bristles of the brush. Earlier, she used to get lot of scolding from her mother on spilling the paste around the sink, while jumping into shower with toothbrush and paste on it. But ever since, she switched to this new toothpaste, there has not been a single spill ever since. Today, she is definitely going to tell her Mother to make permanent switch to this paste. She will recommend the butterscotch flavor to her Mom because she loves it. Wow! A wonderful experience of morning ritual for Alayah’; isn’t it? Let us create use cases for this one. Use case 1: User is delighted with the fact that tooth paste comes in a flavored version and the flavor of the paste is consistent throughout till the last drop in the tube. Use Case 2: User is experiencing a natural growth in well-being of her gums and teeth due to the regular usage of toothpaste and is certified by her dentist also. The noticeable difference comes out in 1 month of regular usage. Use case 3: The user is happy about the quality of the product and feel of it. The flow of the paste is smooth, uniform and consistent. It is firm yet soft to the right degree and grips the bristles of the       brush firmly without leaving behind any residue. Use case 4: The user is happy with the non-slipperiness of the paste as it holds wells on the toothbrush without spilling on to the floor. Use case 5: The user is going to recommend the product to her family members owing to its cost effectiveness, quality of results and number of flavored options available to choose from. In this case, the product manager’s diktat was clear. The toothpaste should be premium feeling with right amount of firmness, variety of flavored options to choose from, health improving and certified. And how did we learn properly? Because we were able to create user stories and use cases properly depicting the right user environments, their interactions with the system and their expected goals from these interactions. This is how use cases add value to the development of right product whether it is software based or manufacturing based or service based. So next time, when you want to ship to the customer, make sure you have all the right user stories targeting the right audience with complete use cases and your product will be a smash hit. This is why, I said, a product manager “creates” use cases and does not merely “write” them. Because while creating use cases, the product owner gets the feel, intent of the product that will surely be missed out if he/she is merely jotting down the requirements or use cases. In my next article, I will share with you on how requirements come out of use cases. Until then, happy creating user stories and use cases and do share your experiences with me on my email or in the comments’ section below. Thank you for your time!  
Use Cases: How Are They Different From User Stories & How To Create Them
Author Image
Rated /5 based on 20 customer reviews
Use Cases: How Are They Different From User Stories & How To Create Them

Use Cases: How Are They Different From User Stories & How To Create Them

Abhinav Gupta
I could have used the word, “write” instead of “create” use cases. But I didn’t. If you know why, then you are already expert on this topic, so please do share your opini...
Continue reading

SUBSCRIBE TO OUR BLOG

Share Blog

View All Topics

Follow Us