top

Search

A Beginner’s Guide To Project Management – Part 1

PMP, Prince, PMBoK, Templates, deadlines, communications, charter, review books, meetings and what not! Project management is a heavy duty exercise that takes up so much involvement from a person yet most of the time it is a thankless work [from my personal experience]. And that is because excellence in this field is considered as expected. Hence the chances of you failing or letting someone down are very high. In this post, let me share with you some of the tips and tricks to make project management easier for you based on my 11 years of experience in this field. I have been burnt many times and hurt quite a few times. And excelled multiple times. The basic problem with Project Managers The basic problem with project managers is they are a pain in the neck [for the lack of better term] for their team. They nag their team members and leads constantly about cost, schedule and most often ask them to work overtime or on the weekend. Aren’t these the reasons why we used to hate our project managers when were engineers? And trust me, these are the reasons your team does not like you now. After being on both sides of the fence in my career, I can now totally understand the pain and pressure project managers go through. We are also human beings and we do not want to harass our team by constantly asking them to provide tracking data, validation arguments, and checking costs. But due to our circumstances, we have no option. So why do we do this? Because we don’t have any better way to do it. But not anymore. Let me tell you some of the tips that will help you. Steps of IPECC In order to help align your thoughts with the management tips and tricks, let me go in order of the IPECC [Initiation, Planning, Execution, Control and Closure] areas. 8 challenges affecting software project management | CIO #PMOT #ProjectManagement https://t.co/r1rG9oeL5n — Project Insight (@ProjectInsight) May 5, 2016 How to save time and escape problems in Project Initiation? Many would think that project initiation stage is very simple and small to bother anyone. You are right. But the real danger of this stage occurs during the control stage wherein you try to control escalating costs, off-track schedule and suddenly you get to know that people who made the charge have moved on and are unanswerable, or you do not have the same amount of control you thought you would have. Has this happened to you? If yes, then read on. If this has never happened to you, then keep the notes handy with you as you could be next! Trust me! No one gets spared! Tip # 1: Take control of the project, officially. After you have been assigned a particular project, take it in writing from the project sponsors. The written confirmation should have the following things clearly mentioned in it: The duration of your engagement in the project The clause of renewal The success criteria of the project What you are authorized to do The things you are not authorized to do And that written confirmation should be signed by the project sponsors with the dates. This confirmation need not be in a single document; although it is preferable. Tip # 2: Know the people who can influence your project Officially this is known as stakeholder register. But I am not talking about that one. I am talking about something more sinister, a hidden plot to derail you that is unfolding while you are focusing on your project. I am kidding! But I mean business when I say that you should know of all the forces that can influence your project either personally or professionally. They could be your friends, foes, colleagues or family. Always keep a map ready in your mind that tells you who can add up to your strengths and who might be the cause of your downfall.  This will also help you distinguish between a well-meant scolding and a misleading appreciation. Tip # 3: Plan in chunks, the smaller the better If you straight away create a plan that covers all aspects, all scenarios from start to finish, then it will definitely please your seniors. But it will harm your team as the plans would become outdated soon. If you choose to go just in time approach for planning, then you might be the cause of bottleneck for your team. So here’s what you need to do: Prepare a broad outline of all the things you need to cover Along with the detailed plan of the very next stage your team needs to do Run these 2 items with your seniors to get their buy-in, in writing of course. Then share these plans with your team ensuring that your leads are completely on-board with your plans.  This way your planning will always be one step ahead of the team’s progress and not be outdated at the same time. Tip # 4: Involve your team in planning I would like to say, teams that plan together sail together. Else you run the burden of multiple project meetings, getting sign-offs and commitment issues from the team. By including the team in your planning, you achieve following things: Complete and real picture of ground reality that allows your plan to be as close to reality as possible You get to know bad apples and good apples in the team first hand by means of their interaction during the planning You gain firsthand knowledge of dynamics within the team The Team buys into the plan because they have helped create it This way you will be saving a lot of time from recurring meetings, review, pushing people to get things done and conflict management. Tip # 5: Get in external reviewers early in the game By getting external reviewers early in the game, you safeguard yours and the team’s interests in multiple ways. Let me elaborate: The viewpoints of external reviewer will allow you to dispassionately review the project and deliverables and thus create a higher quality of products. The team is fully aware that no amount of politicking or gaining favors with management will allow them to escape from an independent external review and thus, self-quality control. In tough times, when your decisions and approach of the team will be questioned by stakeholders, these records of external validations will help you present your case on a strong foot. The External review will help you forecast trends and upcoming challenges early in the game. If we do not opt to do this earlier than in times of escalations, the external agencies are looped anyways by the investigating committees and at that time, you have no say in the matter and you cannot stop the vested interests from bringing external auditors of their choice. So take a bold step and involve external reviewers early in the game and document every review with findings, actions taken by the concerned people. These are just 5 tips to handle initiation and planning aspects of project management in a smarter manner that helps your cause and reduces the number of brickbats that you get from teams. Stay tuned for more such tips and tricks in the upcoming posts on “beginner’s guide to project management”.
A Beginner’s Guide To Project Management – Part 1
Abhinav
Rated 4.0/5 based on 38 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.

Abhinav Gupta Articles

A Beginner’s Guide To Project Management – Part 1

PMP, Prince, PMBoK, Templates, deadlines, communications, charter, review books, meetings and what not! Project management is a heavy duty exercise that takes up so much involvement from a person yet most of the time it is a thankless work [from my personal experience]. And that is because excellence in this field is considered as expected. Hence the chances of you failing or letting someone down are very high. In this post, let me share with you some of the tips and tricks to make project management easier for you based on my 11 years of experience in this field. I have been burnt many times and hurt quite a few times. And excelled multiple times. The basic problem with Project Managers The basic problem with project managers is they are a pain in the neck [for the lack of better term] for their team. They nag their team members and leads constantly about cost, schedule and most often ask them to work overtime or on the weekend. Aren’t these the reasons why we used to hate our project managers when were engineers? And trust me, these are the reasons your team does not like you now. After being on both sides of the fence in my career, I can now totally understand the pain and pressure project managers go through. We are also human beings and we do not want to harass our team by constantly asking them to provide tracking data, validation arguments, and checking costs. But due to our circumstances, we have no option. So why do we do this? Because we don’t have any better way to do it. But not anymore. Let me tell you some of the tips that will help you. Steps of IPECC In order to help align your thoughts with the management tips and tricks, let me go in order of the IPECC [Initiation, Planning, Execution, Control and Closure] areas. 8 challenges affecting software project management | CIO #PMOT #ProjectManagement https://t.co/r1rG9oeL5n — Project Insight (@ProjectInsight) May 5, 2016 How to save time and escape problems in Project Initiation? Many would think that project initiation stage is very simple and small to bother anyone. You are right. But the real danger of this stage occurs during the control stage wherein you try to control escalating costs, off-track schedule and suddenly you get to know that people who made the charge have moved on and are unanswerable, or you do not have the same amount of control you thought you would have. Has this happened to you? If yes, then read on. If this has never happened to you, then keep the notes handy with you as you could be next! Trust me! No one gets spared! Tip # 1: Take control of the project, officially. After you have been assigned a particular project, take it in writing from the project sponsors. The written confirmation should have the following things clearly mentioned in it: The duration of your engagement in the project The clause of renewal The success criteria of the project What you are authorized to do The things you are not authorized to do And that written confirmation should be signed by the project sponsors with the dates. This confirmation need not be in a single document; although it is preferable. Tip # 2: Know the people who can influence your project Officially this is known as stakeholder register. But I am not talking about that one. I am talking about something more sinister, a hidden plot to derail you that is unfolding while you are focusing on your project. I am kidding! But I mean business when I say that you should know of all the forces that can influence your project either personally or professionally. They could be your friends, foes, colleagues or family. Always keep a map ready in your mind that tells you who can add up to your strengths and who might be the cause of your downfall.  This will also help you distinguish between a well-meant scolding and a misleading appreciation. Tip # 3: Plan in chunks, the smaller the better If you straight away create a plan that covers all aspects, all scenarios from start to finish, then it will definitely please your seniors. But it will harm your team as the plans would become outdated soon. If you choose to go just in time approach for planning, then you might be the cause of bottleneck for your team. So here’s what you need to do: Prepare a broad outline of all the things you need to cover Along with the detailed plan of the very next stage your team needs to do Run these 2 items with your seniors to get their buy-in, in writing of course. Then share these plans with your team ensuring that your leads are completely on-board with your plans.  This way your planning will always be one step ahead of the team’s progress and not be outdated at the same time. Tip # 4: Involve your team in planning I would like to say, teams that plan together sail together. Else you run the burden of multiple project meetings, getting sign-offs and commitment issues from the team. By including the team in your planning, you achieve following things: Complete and real picture of ground reality that allows your plan to be as close to reality as possible You get to know bad apples and good apples in the team first hand by means of their interaction during the planning You gain firsthand knowledge of dynamics within the team The Team buys into the plan because they have helped create it This way you will be saving a lot of time from recurring meetings, review, pushing people to get things done and conflict management. Tip # 5: Get in external reviewers early in the game By getting external reviewers early in the game, you safeguard yours and the team’s interests in multiple ways. Let me elaborate: The viewpoints of external reviewer will allow you to dispassionately review the project and deliverables and thus create a higher quality of products. The team is fully aware that no amount of politicking or gaining favors with management will allow them to escape from an independent external review and thus, self-quality control. In tough times, when your decisions and approach of the team will be questioned by stakeholders, these records of external validations will help you present your case on a strong foot. The External review will help you forecast trends and upcoming challenges early in the game. If we do not opt to do this earlier than in times of escalations, the external agencies are looped anyways by the investigating committees and at that time, you have no say in the matter and you cannot stop the vested interests from bringing external auditors of their choice. So take a bold step and involve external reviewers early in the game and document every review with findings, actions taken by the concerned people. These are just 5 tips to handle initiation and planning aspects of project management in a smarter manner that helps your cause and reduces the number of brickbats that you get from teams. Stay tuned for more such tips and tricks in the upcoming posts on “beginner’s guide to project management”.
A Beginner’s Guide To Project Management – Part 1
Author Image
Rated 4.0/5 based on 38 customer reviews
A Beginner’s Guide To Project Management – Par...

PMP, Prince, PMBoK, Templates, deadlines, communications, charter, rev... Read More

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 4.0/5 based on 2 customer reviews
ITIL Practitioner – Things To Be Aware Of

ITIL stands for Information Technology Infrastructure Library and it i... Read More

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 4.0/5 based on 20 customer reviews
10 deadly myths of Agile and Scrum

Agile and Scrum have been conquering the minds of engineers, managers ... Read More

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 4.0/5 based on 20 customer reviews
Value Proposition of Agile Development

Value Proposition of Agile Development The benefits of Agile deve... Read More

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 4.0/5 based on 20 customer reviews
PMP or Prince 2 – The Management Certification S...

If you have arrived at this blog and are actually inclined to read it ... Read More

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. 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 4.0/5 based on 20 customer reviews
Guiding Principles of Agile and Scrum

  “Guiding Principles” are the set of values and propositions ... Read More