Search

Trending blog posts

Project Management Processes: An Overview Of The Stages

The project management processes as defined by PMI® PMBOK® 6 consists of Initiating, Planning, Executing, Monitoring and Controlling and Closing. Every project is a temporary endeavor and will need to be executed well based on the proper planning to avoid unnecessary overruns and schedule deviations. Managing projects is no wonder a challenge that entails conceiving a certain strategy and creating a workable methodology apart from problem-solving, communication, and team-building skills. These parameters divide a project into different phases as defined by PMI’s PMBOK and understanding and applying these PM process will help to acquaint with project management process and why it is necessary to execute a project in specific steps.The following video will walk you through the different stages and processes involved in project management.Let us now see how the project lifecycle interacts with overall project management process. In predictive small projects, the project management processes will be followed throughout the entire project though some of the processes may be iterated throughout the cycle.Nevertheless, large projects may require each lifecycle phases to be managed by the process groups. The example given below has each phase of the project lifecycle go through the project management process groups due to its demand. An overall initiating effort will be done by the project manager leading to project charter creation and do high-level planning to get approvals. Once this is done, there would be separate phases for each stage in the project planning, execution, control, and closure which would typically hand out deliverables for that phase. Then the project management process will be repeated for the next stage of the project lifecycle.The initiating process formally kickstarts the project or project phase. This involves identifying and analyzing stakeholders for alignment with their goals and objectives. This phase provides a guiding vision for the project that will help achieve high-level scope and any known constraints. The initiating phase formally gives the project manager the needed authority and information necessary to start the project.The output of the initiating phase is project charter and stakeholder register.Project Planning is a very important phase of any project that gives details about the project and helps in getting it organized before the start of the work. This presents a great opportunity to save time, cost, and resources. In the planning phase, the project manager and the team performs a detailed analysis of whether the project can be executed according to the details present in the project charter. Then they decide on how to achieve the strategic objectives through the project management process and knowledge areas. The project planning is iterative and not a one-time effort. This is because each process will use the results of the previous processes and may affect the outcomes. In the real world, the project plan and documents are revisited after identification of the risks, performing qualitative and quantitative risk analysis. The level of project planning by the project manager and the team always depends on the needs of the project. A highly visible project on an accelerated timetable with very limited variance demands detailed project planning rather than a low priority project with adjustable schedules.The output of the planning process are project management plans and project documents that will provide directions for execution and control of the project.The objective of executing process group is to complete the work defined in the project management plans to meet the objectives. The main goal is to achieve the outcome by adhering to budget, timeline, and schedule as mentioned in the project management plan and project documents. This phase is where the actual work will be done and will be focused on managing process, people and communicating according to plan. The project manager constantly updates the project management plan and project documents to accurately reflect the current status of the project. He or she also creates issues log to record and maintain project issue details, resolution and also who will be responsible for resolving the issues within the time.Monitoring and Controlling process will measure the actual performance of the project against project management plan and approving changes through change management including corrective and preventive actions along with defect fix. The project manager uses the project baseline documents (scope, cost, schedule) to compare against the actual performance and suggest course corrections. He/She also obtains formal acceptance of interim deliverables from the customer. If the project does not go according to plan due to scope changes, the project manager re-plans and makes updates to the project management plans and project baseline documents to reflect the approved changes.The final processes group is the closing group where the product scope is completed. This will have administrative activities including finalizing the paperwork needed to finish the project. The project will also have retrospectives from customers and team that goes into the “lessons learned” document. The project manager ensures all the project management documents are updated to complete status and hands off all project deliverables to appropriate stakeholders.ConclusionThe project management process is the core of any project that helps the project manager navigate through all issues that arise in the project. The project management plans and the baseline documents serve as important documents and a guiding light for the project manager to make the project a great success.
Project Management Processes: An Overview Of The Stages
Ram kumar
Rated 4.0/5 based on 2 customer reviews

Project Management Processes: An Overview Of The Stages

The project management processes as defined by PMI® PMBOK® 6 consists of Initiating, Planning, Executing, Monitoring and Controlling and Closing. Every project is a temporary endeavor and will need to be executed well based on the proper planning to avoid unnecessary overruns and schedule deviations. Managing projects is no wonder a challenge that entails conceiving a certain strategy and creating a workable methodology apart from problem-solving, communication, and team-building skills. These parameters divide a project into different phases as defined by PMI’s PMBOK and understanding and applying these PM process will help to acquaint with project management process and why it is necessary to execute a project in specific steps.The following video will walk you through the different stages and processes involved in project management.Let us now see how the project lifecycle interacts with overall project management process. In predictive small projects, the project management processes will be followed throughout the entire project though some of the processes may be iterated throughout the cycle.Nevertheless, large projects may require each lifecycle phases to be managed by the process groups. The example given below has each phase of the project lifecycle go through the project management process groups due to its demand. An overall initiating effort will be done by the project manager leading to project charter creation and do high-level planning to get approvals. Once this is done, there would be separate phases for each stage in the project planning, execution, control, and closure which would typically hand out deliverables for that phase. Then the project management process will be repeated for the next stage of the project lifecycle.The initiating process formally kickstarts the project or project phase. This involves identifying and analyzing stakeholders for alignment with their goals and objectives. This phase provides a guiding vision for the project that will help achieve high-level scope and any known constraints. The initiating phase formally gives the project manager the needed authority and information necessary to start the project.The output of the initiating phase is project charter and stakeholder register.Project Planning is a very important phase of any project that gives details about the project and helps in getting it organized before the start of the work. This presents a great opportunity to save time, cost, and resources. In the planning phase, the project manager and the team performs a detailed analysis of whether the project can be executed according to the details present in the project charter. Then they decide on how to achieve the strategic objectives through the project management process and knowledge areas. The project planning is iterative and not a one-time effort. This is because each process will use the results of the previous processes and may affect the outcomes. In the real world, the project plan and documents are revisited after identification of the risks, performing qualitative and quantitative risk analysis. The level of project planning by the project manager and the team always depends on the needs of the project. A highly visible project on an accelerated timetable with very limited variance demands detailed project planning rather than a low priority project with adjustable schedules.The output of the planning process are project management plans and project documents that will provide directions for execution and control of the project.The objective of executing process group is to complete the work defined in the project management plans to meet the objectives. The main goal is to achieve the outcome by adhering to budget, timeline, and schedule as mentioned in the project management plan and project documents. This phase is where the actual work will be done and will be focused on managing process, people and communicating according to plan. The project manager constantly updates the project management plan and project documents to accurately reflect the current status of the project. He or she also creates issues log to record and maintain project issue details, resolution and also who will be responsible for resolving the issues within the time.Monitoring and Controlling process will measure the actual performance of the project against project management plan and approving changes through change management including corrective and preventive actions along with defect fix. The project manager uses the project baseline documents (scope, cost, schedule) to compare against the actual performance and suggest course corrections. He/She also obtains formal acceptance of interim deliverables from the customer. If the project does not go according to plan due to scope changes, the project manager re-plans and makes updates to the project management plans and project baseline documents to reflect the approved changes.The final processes group is the closing group where the product scope is completed. This will have administrative activities including finalizing the paperwork needed to finish the project. The project will also have retrospectives from customers and team that goes into the “lessons learned” document. The project manager ensures all the project management documents are updated to complete status and hands off all project deliverables to appropriate stakeholders.ConclusionThe project management process is the core of any project that helps the project manager navigate through all issues that arise in the project. The project management plans and the baseline documents serve as important documents and a guiding light for the project manager to make the project a great success.
Rated 4.0/5 based on 2 customer reviews
Project Management Processes: An Overview Of The Stages
Blogs
127
Project Management Processes: An Overview Of The S...

The project management processes as defined by PMI... Read More

7 Levels in Delegation Poker Group activity - Project Management

Delegation is something that every Project Manager should know. We need to delegate tasks to get rid of the Monkeys. Here, Monkeys are nothing but the ‘next move’ as described in the book- ‘The One Minute Manager meets the Monkeys’ by Ken Blanchard, William Oncken, Hal Burrows .Poker is a family card game that everyone played at least once. We live in a reality where ‘I don’t have time’, an excuse is heard constantly and we refuse to find time for playing in our adulthood – so why not to do it at work?Delegating the tasksThe truth is, no matter how good you are, you won’t complete a project by yourself. You don’t have all the skills that are needed, and probably even time for that during the working day. You need to know how to delegate tasks – which is really not an easy job!We, as the Project Managers, need to encourage teams to self-organise themselves. We’re here to be a part of a team, help, and lead, but not to manage (at least not anymore). We need to make sure that the team members trust each other, can run projects in a collaborative way (thanks to the combination of skills that team has), and that everyone is clear about their responsibilities and roles. By distributing control and delegating, we empower people, but as much as we want to give the team a freedom, we must set some boundaries.As you can imagine, it is difficult to not only decide which tasks should go to whom, but also which level of decision-making process others should have on a given task. Delegation Poker cards will definitely save the day.Delegation PokerHow to start? Get your cards! You can either order a set from the Management 3.0. shop or just download a deck of cards (which are available in 14 languages!)You’ll find 7 levels of responsibility on the Delegation Poker cards. It goes from I’ll do that so I’ll be an observer, they’ll do that. Let’s take a closer look at the cards:1) Tell, I will tell them – The highest level of the responsibility, a person will make decisions and inform others about them, he or she doesn’t need to consult topic with others or try to convince them2) Sell, I will try and sell it to them – A person knows what he or she is doing, but wants the rest of the team to like it too. The decision stays with the person, but the vision is shared.3) Consult, I will consult and then decide – On the 3rd level you don’t make a decision by yourself, there are tasks that people have more experience with, and where collaboration is required to find the best solution. Decisions are still made by a person with this level but it happens after consultation with other team members4) Agree, we will agree together – You’d think that it’s an ideal level where everyone needs to agree with each other and the decision belongs to the whole team. There are situations where that’d work, however, we need to be careful to not to find ourselves with not being able to make any decisions or debating on things that should be fixed (e.g. you probably don’t want to give a product’s quality under discussion)5) Advise, I will advise but they’ll decide – A person gives away the final decision but shares experiences and can give an advice6) Inquire, I will inquire after they decide – Someone else will make a decision and a person with this delegation level will just check later what the decision is, or will be informed about the decision.7) Delegate, I will fully delegate – It’s a very useful level if you don’t have the skills needed for a task, and somebody else has them. Delegate and trust – if you’re a Project Manager, you’ll probably leave configuring the database to the IT Specialists, right?Now, you need is a set of predefined situations or cases that you want to delegate. Remember, you’re part of a team, so it’s important to include some of your tasks so that the team would be able to decide about their level of delegation (maybe they would like to be informed or consulted on given topics, or maybe you want and need to delegate some of your responsibilities).You have cards, prepared cases and you have your team. Let’s start!The GameGive a deck of cards to every team member. Explain the game to the team, so everyone would understand the delegation levels and why you run the game. Make sure that a group that debates the delegation levels is not bigger than 7 people, if it happens, then just split your team into smaller ones.Choose a topic – one of the team members reads out loud one of the pre-defined scenarios, he or she describes a given story from their own experience.Each player chooses a card that in his or her opinion describes the needed delegation level, when everyone decided, reveal the selected cards. There will be differences (and here the fun begins!) let people with the biggest different discuss.  There’s a lot of value in these discussions, there might be clarifications made, maybe a new scenario will get created, but you’ll see how the team sees their roles.Create a boardMake sure to write down the results and make it visible for everybody. You might want to have a board with all the stories and levels agreed to given roles. It might happen that when you complete the game, and you’ll see a whole, bigger picture, you’d want to re-do some of the cases. And it’s ok to do that! As long as you achieved consensus and everyone is clear about their responsibilities, play as many times as you need to!Learning objectivesAs you can imagine, the main outcome of the game is to know who is responsible for what and at which level. You’ll definitely have fruitful discussions and will learn something new about each other, about your views and how you see yourself as a team.Following the Management 3.0. objectives, you’ll learn that:Delegation is not black and white - you will find areas that are in between, where you can’t fully agree and make a perfect decision on……and sometimes it depends on the context - there will be cases where a delegation level depends on a nature of a given task and you can’t create a general rule that suits allDelegation is a process – don’t think that you play today and you give away tasks tomorrow morning. It doesn’t work this way, there must be a transition time, you will handover tasks in a pace in which others can take them, collaborating.Whether you’re a beginner in the self-organising teams world or a professional with years of experience, you’ll always learn something new. There is not a workshop that you can run that won’t be unique. Everyone has a different background and experiences, and that makes everything interesting. And remember – no matter how resistant your team might be, if you tell them that the next meeting will be actually a game, they won’t say no to fun!
Rated 4.0/5 based on 0 customer reviews
7 Levels in Delegation Poker Group activity - Project Management
Blogs
324
7 Levels in Delegation Poker Group activity - Proj...

Delegation is something that every Project Manager... Read More

Stakeholder Management in Long Duration Projects - Project Management

If you are working in project management, you know that a key to success is to manage the stakeholders involved. There are articles, webinars, and books about how to successfully understand the science around it. In many cases, you know that you will work with many stakeholders through the years because there are many projects in common, but what if the project was one and the changes came from the roles or even the stakeholders involved?Suppose you have a service contract management with company ABC that is due to last at least five years. So, do I have the same approach as it was a one or two-year project? And here comes the funny part, yes or no.STAKEHOLDERS MANAGEMENT ACCORDING TO PMIChapter 13 of the PMBOK® defines the Project Stakeholder Management as “…the processes required to identify the people, groups, or organizations that could impact or be impacted by the project, to analyze stakeholders expectations and their impact on the project, and to develop appropriate stakeholder management strategies for effectively engaging stakeholders in project decisions and execution…”. I bring all the definition so you can see the words involved in it, identify – expectations – impact – engaging. Those are the keys to success.According to the PMBOK®, the four processes in the stakeholder management are identifying the stakeholders and their planning, managing and monitoring their engagement in the project attributes. If you see the stakeholder’s management tools and techniques that are set to use in these processes, you can divide them into two main segments, the analytical and the communicational.The Driving process :  For a better Stakeholder ManagementIn both cases, only expertise, common sense and soft skills will guide you and even then, you will probably make a mistake in some moment. Don´t worry, because mistakes are expertise for the future and, believe me, everybody makes mistakes. (That´s part of the risk management)GET A LEVERAGE BY UNDERSTANDING THE ROLESPart of being an effective Project Manager is known for which strings to pull and the ones you must let go. That knowledge comes from listening, seeing and analyzing the non-spoken words in meetings. Just like when in a relationship someone does all the taking but when it comes to decisions always look for the approval of others that haven't said a word, that's the one in charge but probably is not interested in the issue.So, how can I know the level of power, interest, influence or impact of each stakeholder? Do I use the force?How do you analyse your Stakeholder?The first is obvious, talk to people that have been involved in previous projects and try to know the stakeholders involved in the project. You know a guy from another company that worked there? Buy him some coffee and let him explain to you who is who in the company.Or better, some guys in your office have worked there before. Well, let's gather information on which people involved will have more impact on the project, or if someone needs to be informed about every change of scope, etc.You will probably expect that a CEO will have more power than a Manager, so that will be a good approach.However, that's not the case of influence. It could happen that the CEO doesn't know what you will do because that’s not his/her area of expertise, so the manager makes all the decisions and has more influence on the project.Another hint will be clarified in time if you see an attitude from other people involved to always pass all the big decisions to someone specific.If you have the opportunity, during the first meeting when you are developing the scope of the project try to establish how the communication processes will be. There you will see people that want to be informed, the ones that have the final voice, some just need to check on them from time to time and the people you are going to work through the entire project and need to actively be engaged.As you may notice, each one is just an example of common sense that use the communication processes to figure out the data you need to analyze and establish the role of the stakeholders involved in the project. If you know who is who in your project, you will have a leverage.DEVELOP AN AGILE APPROACH ON ROLES OF EVERYONE IN THE PROJECTSo, what you need to keep doing after the project start with the stakeholder’s management?I believe that success in this area came from three things:Knowing rolesHandling expectationsCommunicating effectivelyThese three represents the main questions Who? What? How?Who? You need to know who is who in your project. Some people are there just for the champagne on the podium and some are because they care, you must know which one is relevant.What? The reason many projects fails is that the scope of the project does not reflect the expectations of the stakeholders. You need to know how to handle the expectations and try to be completely clear about them, and if it is written in a document better. There is an article from the editor of knowledgeHut that give you 8 tips on how to handle it effectively.How? You need to know the type of communication you need to use in each case. Maybe is in a meeting, or by an official document, even drinking coffee, you need to understand the moment and the way to do it. For instance, if some parts are delivered with delay and it implies a financial hit to the project it's better to talk in private first and deliver the news, then write an official document. Communicate effectively.When you are working on projects that will have an extended duration you need to know that the roles will change. As certain as the sun will rise tomorrow, people will get in and out of the project or even of the company. I am a faithful admirer of the waterfall, but in the world, we are living, every information is just a stone’s throw away; you need to develop an agile approach in many things, even in this. Some will change roles within the project, maybe the project leader will become a manager and his interested will change with his power, maybe some guy has an opportunity closer to where he grew up, it doesn't matter, in a project that lasts so long change will come.There are things you need to keep doing along the project´s run:Be informed by external references:You need to be informed of all possible changes that will affect your project. Make alerts in google news or read papers, it doesn't matter, you need to stay ahead of the game. For instance, if you are working with the federal government and a scandal get to the news, you should be aware that many people will probably change, be prepared and try to follow any information.Gather information from people:If you don't like diplomacy and the importance of it, I truly advise you to see Game of Thrones. You don't need to like all the people involved, but you can make them inform, warn or advise you. Try to get ahead of the game and gather information about the new people involved or the new roles that will change. Being a Project Manager is not easy and will always require the extra mile to diminish the possibilities that some event make the project fail.Effectively archive documents:I know that it sounds absurd, but many Project Managers fail in this. If you see that some guy, that you don't know, is making all the changes when you read the history in the reply of the last emails, then this guy has influence-power in the project.Make less but effective meetings:It is absurd the amount of time we waste in nonsense meetings, so make them count and anyone involved in the project will try to be there. In them, you will update the roles of each stakeholder. Prepare meetings and give with a couple of days before so everybody knows all that will be discussed in them, try to establish who will be attending. “If you book them, they will come” Wayne Worlds 2.LONG TIME PROJECTS STAKEHOLDER´S RELATIONSHIPSMany of the success involved in getting a good relationship with the stakeholders in long projects is based on handling the expectations. Notice that you can develop a relationship of friends or you don't see them again when the project finish, but I will try to explain how to achieve good relationships, that will help you get successful project by managing expectations.Building  a great AllianceRemember when you were a kid and you will open Christmas presents? After you did an amazing letter to Santa where you describe that you want the Lego´s Falcon Millennium, there were three choices:You get the Falcon Millennium toy, not the Lego. You are getting something similar but not what you asked.You get the Lego´s Falcon Millennium. Yes, yes. Exactly what I asked.You get the USS-Enterprise. Not even close.The same happens with the expectations in a project with the possibility to see all the process from the letter, the elf determined the possibilities (if you were good or bad), the assembling, the package and delivering. So, if you see something strange you can put a red flag.That's what happens in real life. The things the stakeholders want maybe are not possible. Your client wants the project to be built in three months, your boss wants 2% of cost reduction or the subcontractor established that he will not start until all equipment is in place. These are common things, many of them need to be established when making the scope of the project, but you need to keep all of them aware of the reality of the project. Don´t accept any request if it is not the reality of the project.Some of them will bring discussions and will mean roughness in the relationship but is better to bring people down to earth from two feet that bring them at 5.000.In the paper written by Ernest Baker in 2012 “Planning effective stakeholder management strategies to do the same thing”, he mentions tools for setting and managing expectations.“…Stating the success criteria (project objectives) in the project charter.Defining what is in and out of scope in the project scope statement.Defining and getting agreement on the project deliverables documented in the WBS.Creating and sharing the project schedule or release burndown charts.Documenting who on the project team does what in a responsibility assignment matrix (RAM) or RACI chart.Creating and using a communication planning table to show how stakeholders will be kept in the loop for project information.Creating and posting project dashboards for the PMO or senior leadership.Creating, leveraging, and using project subsidiary management plans to handle all the processes necessary to define and manage the various parts of the project. These sets of guidelines, or rulebooks, list the “how's” to do the various project management processes.Conducting project kickoff meetings to publically state project objectives and set stakeholder expectations.I believed that it is also significant to have a documented change requested process, so any change made from the initial scope needs to be understood (with all the implications of it) and accepted by the stakeholder´s initially established as the ones to possibly do it. Cause, in many opportunities, you will need to change the reality to meet the expectation of some stakeholders, but need to keep track of anything that will mean a change in time, quality or cost.If you keep the expectations and project reality closed to each other, you will have good relationships during the project´s run. once it is finished, you will decide which  relations are worth keeping and those who don't. It will be because you see an opportunity in the future, because you liked them and have affinities or because you will still work with him.You need to understand that keeping track on relationships in this hi-tech world is as easy as writing congratulations on their birthday or an email once every year. Most people want to feel that meant for help in the progression of someone as if they really do than shame on you for not doing it.CONCLUSIONMany of the “magic” of an effective stakeholder management comes knowing the roles, handling expectations and being an effective communicator. It means to gather information, a bit of diplomacy, analyze information and a lot of common sense (not so common after all). But in long time projects, it is all about keeping the gap between reality and expectations the closest as possible.
Rated 4.0/5 based on 2 customer reviews
Stakeholder Management in Long Duration Projects - Project Management
Blogs
307
Stakeholder Management in Long Duration Projects -...

If you are working in project management, you know... Read More

How are Changeless Principles Responsible For Project success In Software Industry?

IntroductionNo other industry perhaps is characterized by a change as much as the software industry. While every segment of society and more so the industry, goes through change, the pace and magnitude of change in the software industry are leaps and bounds ahead of all other segments.This magnitude of change can be unsettling as just when one thinks that one has cracked the secret of success, the rug is pulled from under the feet by the change and success formulae have to be reinvented all over again. In such turbulent scenarios, how do leaders respond to the changes and succeed? What is their recipe for success?This article is about how leaders don’t get swept away by the changes but respond smartly to the changes in a thoughtful manner. They hold the bull by the horn, so to say, and rule the changes rather than being dictated by the changes. One of their secrets to success is that they anchor themselves in constant principles that don’t change and respond to changes based on these changeless principles.What are these changeless principles of the software industry? This article highlights 5 most impactful principles that don’t change and have lead to proven success in software delivery.What are the changeless principles?The changes in the software industry happen in almost all facets, be it technology, software development methodologies, and life cycle models, business model, contract types, you name the facet and you can see changes.Specifically, 5 types of changes impact software project success significantly and they are requirement changes, the life cycle model changes, estimation methods becoming obsolete, project scheduling methods becoming ineffective and the emergence of new risks.Every change brings along with it new challenges and simply embracing the change can potentially create new problems while solving some old problems. Slogans such as “Don’t resist the change, embrace it instead!” or considering being open to changes as a virtue aren’t enough to succeed amidst the change.For instance, when an estimation methodology becomes obsolete because of a new technology, what does one mean by not resisting the change or embracing the change?Teams simply become technically competent in the new technology but regress back to raw, unstructured estimation method rather than creating a new estimation method. However, leaders respond to changes differently. They step back and look at the change from a meta-level, realize that the meta-principle that hasn’t changed and re-apply that meta-principle to the changed situation and remain effective.Coming back to the estimation example, when an existing estimation method becomes obsolete with the change of technology, they look at the meta-procedure of creating estimation method itself (Which doesn’t change) and create a new deliverable-based estimation methodology for the new technology rather than regressing back to raw, unstructured estimation methods.Thus they maintain estimation accuracy and project success in spite of the change. On these lines, the following are the 5 principles that don’t change in the software industry:1) The Principle of requirement change: Encourage changes occurring due to external factors but discourage or eliminate changes occurring due to the  internal factors. This principle doesn’t change irrespective of the emergence of new ways of managing requirements.2) The Principle of life cycle models: The 5 phases of any life cycle don’t change and you should create your own life cycle model when faced with a new situation. In spite of new life cycle methods emerging, the 5 phases namely, requirements, solution specification, a design of the solution, implementation of solution and testing of solution don’t change. One can always tailor-make these 5 phases to create a new life cycle.3) The Principle of estimation methodologies: The procedure to create deliverable based estimation methodologies does not change; create a new deliverable-based estimation method when technology changes. Established estimation methodologies become obsolete when technology changes but the meta-method of creating a new estimation methodologies doesn’t change. Hence, creating new estimation methodology using this meta-method is essential to maintain estimation accuracy.4) The Principle of schedule management: Project schedules are effective when the work breakdown is aligned with the life cycle model and contains at least 90% of the tasks performed by the team on the ground.  As life cycle models change, old methods of drawing up project schedules become ineffective and teams either give up drawing an effective schedule or draw schedules that are not used. However, aligning the schedules to the new life cycle models ensures that schedules are effective and results in optimum resource utilization.5) The Principle of risk management: It is essential to prioritize identified risks and plan mitigation and contingencies irrespective of size and complexity of the project. The types of risks may vary as project environment changes, but the basic principle of risk prioritization, mitigation ,and contingency planning does not change. As contract types, business models, life cycle models and technologies change, the types of risks may change, but the basic principle of risk management do not change and this has to be implemented completely to increase chances of project success.Why only these 5 principles? Are there not other principles that are important? Well, there could be many principles that don’t change and have to be applied for project success, but these 5 are the most important principles critical to project success and the most challenging too.There are principles related to the stakeholder management, product design, testing, team management and so on, but dealing with all of them would perhaps be apt for a complete user manual on changeless principle and not for an article. Hence 5 most important principles have been chosen for illustration in this article.Illustration of the 5 principles1) The Principle of requirement change:Encourage changes occurring due to external factors but discourage or eliminate changes occurring due to internal factors.Well, requirement changes are the order of the day in software projects and the way requirement changes are managed differs with software development methodologies and life cycle models. While the earlier CMMi based school of thought insisted on defining and signing off on requirements early in the lifecycle and keeping the changes to a minimum subsequently, the Agile school of thought went to another extreme saying that they encourage requirement changes and both are right in their own perspective.While minimum requirement changes are good for the stability of the project in terms of conformance to plan, encouragement for requirement changes could be good for business success as business scenarios can be dynamic and IT should keep pace with business dynamics.So, it is clear that there is an Agile wave now and it is altering the way that we look at the requirement changes. And, let’s see how the mass goes with this change and how leaders respond. Those who simply “Embrace” the change, go with Agile methodologies at face value, accept that requirements can keep changing and suffer the consequences.For instance, some IT vendors enter into fixed-price contracts for Agile projects based on some initial understanding of scope, and because of progressive elaboration of scope, the customer keeps giving requirements at every release which bloats the scope so much that the project easily gets into schedule overruns and cost overruns. This could result in losses for the vendor and if not handled well, it could result in dissatisfaction of the customer and loss of business as well. However, thought leaders take a step back and look at why requirements change and come up with responses that keep both customer interest and their own interest in mind. Leffingwell et. al.[1] have researched into why requirements changes and classify the causes into two sets called internal factors and external factors.Internal factors have to do with who we elicit requirements from, and how we elicit requirements. If requirements are not elicited from the right stakeholders and if the right elicitation techniques are not used, then it results in unclear and incomplete requirements leading to subsequent changes. Such changes are avoidable through the appropriate usage of elicitation techniques and documentation.This is why the BABoK (Business Analysis Body of Knowledge)[2] lists more than 30 techniques to elicit, analyze and document requirements. These techniques have to be used effectively to eliminate changes occurring because of internal factors.The external factors, on the other hand, have to do with changes to market conditions, competitive landscape, and legal compliance needs. The changes are needed for the business success of the projects and can’t be easily foreseen.Postponing such changes may have serious, adverse impact on business objectives and hence such changes must be accommodated into the present release as quickly as possible. Leaders who succeed with Agile projects follow this principle, insist on upfront clarity in scope at a high level and then allow progressive elaboration of scope over the releases for more details.That is, they use a multitude of apt techniques to elicit and document requirements from the right stakeholders upfront so that their get clear and complete requirements and hence eliminate changes occurring due to internal factors.However, they would not insist on “Freezing” the requirements but allow progressive elaboration of details of these requirements to accommodate changes happening due to external factors. Thus they achieve both interests – proper estimation and planning for efficient delivery and cost-effectiveness through upfront clarity and completeness of high-level requirements and also ensure quick alignment with changing business scenario through a progressive elaboration of detailed requirements.2) The Principle of life cycle models:The 5 phases of any life cycle don’t change and you should create your own life cycle model when faced with a new situation.Lifecycle models keep emerging and every time there is a new lifecycle model, it impacts the project schedules, communication reports, team ramp up and ramp down plans, and quality plans mainly. However, as some industry experts such as Karl Wiegers [3] suggest, these life cycle models have little difference and the masses may get swept away by the hype involved in the new lifecycle model but leaders respond differently.Leaders understand that every new life cycle model brings with it solution to some existing problem but also a new set of problems. Hence, they accept the new models selectively and often adapt with the new lifecycle model by tailor-making it to their advantage. They can do this tailoring based on the understanding that the 5 phases of a lifecycle model are changeless.Software development models have emerged under many names beginning from waterfall, V, RAD, evolutionary methods, iterative, incremental, spiral, RUP and finally fully Agile methods such as Scrum, XP, and Kanban. The life cycle models mainly define how the 5 phases such as requirements, functional specification, design, implementation and testing are woven. The fact that any development project, not just the software projects involve all the 5 phases is a changeless principle as established below:Problem definition:This phase can be alternately called Scoping, Requirements Specification etc., and defines what the customer needs are that should be translated into deliverables. Any project exists because there are customer needs and hence this phase cannot be done away with.Solution specification:Alternately called functional specification, analysis phase, feature specification etc., this phase defines what the proposed solution is for the customer need. Any project is an implementation of solution to a customer need and solution definition cannot be done away with.Solution design:Alternatively called design, low-level design etc., this phase defines “HOW” the solution will be implemented. Any nontrivial solution needs to be designed and in that sense, this phase is indispensable too.Solution implementation:Alternatively called implementation phase, construction phase, the coding phase, this phase implements the designed solution. It is this phase that produces the actual deliverables and hence indispensable.Testing:This phase involves multiple types of testing and tests the implemented solution against the specified requirements. No product can be released without testing and this phase is indispensable too.Given that these phases are indispensable, let’s see how different life cycle models weave them. The waterfall model involves a tight sequence among the 5 phases. That is, you cannot skip any phase and work on a phase without completing the previous one. The incremental model breaks down the scope into multiple increments but maintains the tight sequence among the phases within each increment.However, Scrum not only breaks the scope into multiple increments called “Sprints”, but also removes the tight sequence among the 5 phases. For instance, one can do coding for a feature without an approved design for the same.Hence, the Agile model provides more freedom and flexibility to developers compared to the incremental model or the full-fledged waterfall model. While this freedom sounds attractive, if the team is not multi-skilled and seasoned enough, the resulting product may contain spaghetti code and become unmaintainable. Also, if the team is not multi-skilled, the Agile model may not result in optimum resource utilization.Given this backdrop, while the masses embrace the Agile model mechanically and suffer the consequences of chaos and underutilization (while also realizing some benefits), the leaders respond differently. They may adopt Agile fully if suitable, but if not, they create tailor-made hybrid models.Most of the recent successful megaprojects showcased at PMI conferences implemented hybrid models that involved elements of agility but imposed certain discipline as well. The latest version of PMBoK lists hybrid life cycle models as a trend in project management [4].To illustrate a hybrid model, factory model that was one of the many hybrid models implemented in Wipro Technologies and published as a case study at Harvard [5] can be taken as an example.Factory model is a software service delivery model and software development life cycle is only a part of it and this article illustrates only the life cycle part of the factory model. As illustrated in diagram 1, factory model involves frequent releases that are pre-scheduled and requirements are accepted even after the requirements document is signed off and subsequent phases are in progress.However, there is a cutoff date for requirements inflow after which the incoming requirements would be allocated to the next release. As the releases are shorter and the customers have a look ahead, usually they would be willing to wait for the next release rather than pressing for inclusion of requirements into the current release.This is a hybrid model, which has Agile features namely shorter releases and openness to accept requirements even after signing off RS. But, it also has traditional features such as tight binding of life cycle phases within a single release and freezing the requirements beyond the requirement window. There are many such hybrid models used effectively by industry leaders.3) Principle of estimation methodologies:The procedure to create deliverable based estimation methodologies does not change; create a new deliverable-based estimation method when technology changes.As new technologies emerge, one of the consequences is that established estimation methodologies become obsolete. For instance, when the Function Points estimation method was created for COBOL applications, it became quite widely used. The units into which the functionality of an application is broken down into, such as “Internal logical files”, “Record types” etc., was natural to COBOL applications.However, with the emergence of GUI based client-server applications, this model became a force-fit and estimators regressed back to carrying out unstructured raw estimates. This phenomenon happens every time there is a technology change. The masses follow raw, unstructured estimation method but the leaders develop new methodologies themselves.We have carried out research into the accuracy of estimates by asking the groups of people to estimate for the same specification using both raw method and structured methods and the results show stark differences in accuracy. Diagram 2 below contrasts estimates performed using unstructured, semi-structured and formal (completely structured) methodologies:As the above diagram compares estimation results performed by same people on the same specification with estimation method being the only variant, it can be concluded that estimation method plays a major role in determining the accuracy of estimates. Use of semi-structured and fully structured estimation methods improves the estimation accuracy significantly.Hence, the leaders use the changeless procedure to design new estimation methods and come up with a new estimation method themselves when technology changes. This procedure is as follows:Define the measure of application size.Define the units into which the specification is broken into.Define the factors to classify the complexity of the broken down unitsDefine the formula to arrive at size based on the number and complexity of broken down unitsDefine the method to determine effort from the size using productivity norms.This author explains in one of the previous papers [6] how different methodologies can be compared along the lines of the common procedure defined above and compares Function Points, Use case Points, MVC Points and structured WBS methods in a common format as shown in diagram 3 below:The author and colleagues have created two such deliverable-based open estimation methodologies namely MVC Points [6] and Interface points [7] intended to estimate web applications and enterprise application integration projects. We have also seen many unpublished methodologies to estimate data warehousing applications, ERP applications used in-house in leading IT organizations and usage of these methods greatly improve estimation accuracy.4) The Principle of schedule management:Project schedules are effective when the work breakdown is aligned with the life cycle model and contains at least 90% of the tasks performed by the team on the ground.  When life cycle models change, the way work is broken down also changes. It has been illustrated in earlier articles of this author [8][9] that alignment of work breakdown structure to the life cycle model is a critical factor that determines whether the schedule will be used in the project or not. When life cycle models change and the older ways of WBS doesn’t work, the masses give up scheduling practices but the leaders change the WBS and continue scheduling practices to ensure optimum resource utilization.Specifically, the arrival of Agile methodologies has rendered old ways of WBS obsolete. As shown in diagram 4, Agile methods view project progress in terms of completely usable features whereas traditional methods view project progress in terms of work done.Accordingly, the WBS also changes. A WBS of a traditional project would like table 1 belowAs can be seen in table 1, the WBS is organized along life cycle phases. As this does not work with Agile models, the common tendency is to give up schedules and execute work in ad hoc manner. However, leaders transpose the WBS to align with an Agile view of project progress as shown in table 2 and continue to use project schedules to optimize resource utilization.5) Principle of risk management:It is essential to prioritize identified risks and plan mitigation and contingencies irrespective of size and complexity of the project.As changes occur in all facets of project execution, very new risks emerge and a common tendency is not to identify the risks but stick with the old risks and suffer the consequences. However, leaders stick to the constant principle of risk management and use that to identify and manage new risks. The risk management process that doesn’t change is indicated in the following diagram 5:To illustrate, when the outsourcing model changes from tactical outsourcing to strategic outsourcing, new, critical stakeholder risks emerge. When life cycle model changes to Agile, new cost-related risks emerge. However, the leaders stick on to the process of risk identification, risk prioritization, risk response planning and risk monitoring and control to stay on top of risks and maximize project success probability.ConclusionAs changes occur ever more frequently in all facets of software delivery, it is not adequate to respond with rhetoric such as “Embrace the change” or “Be open to change” although they are well-meaning phrases. It is important to respond to the change thoughtfully and taking a step back from the change and identifying the changeless principle behind the change helps in responding thoughtfully.This article has identified constant principles that don’t change in 5 facets of project delivery and anchoring in these changeless principles helps to respond to changes smartly and increase project success chances by leaps and bounds.
Rated 4.0/5 based on 2 customer reviews
How are Changeless Principles Responsible For Project success In Software Industry?
Blogs
305
How are Changeless Principles Responsible For Proj...

IntroductionNo other industry perhaps is character... Read More

Big Bang and Phased approaches – How to do it, and what to expect?

The three most popular frameworks for organizational transformation or projects (having multiple teams) are Big Bang, Phased, and a blend of these two approaches.While Agile itself advocates phased delivery for faster realization of Return on Investment and continuous feedback, it is surprising that to get there, one of the popular approaches is Big Bang implementation approach. I have been in both type of transformations and my experiences (both personal and professional) with both are given below.I have a daughter with terrible eating habits, and I wanted to introduce her to new food, and that’s when I considered the two approaches in my real life scenario.How Big Bang worked in my project:Big Bang – Here all changes are implemented in the bang. All tool changes and process changes everything go together, and often this comes with a lot of confusion and resistance on the team floor.I was a team member when my team transformed through a Big Bang methodology. Our Agile coach gave us a 2 days’ crash course on Agile and Scrum, and one-day training on ALM tool and its discipline, and we started Scrum. This change brought in a sudden sense of insecurity and fear among us, we were scared of failing. We were all talking and complaining. But we knew that the change had to be accepted since there was no fallback option. In a few weeks, we were in Agile –and we were using the tools effectively, this could be because the customer had a high focus on them, but it worked. Many still complained and looked for opportunities to compare or fallback.This went on till we started comparing ourselves with other teams which were non-agile. We realized that other teams around us wanted to be like us, they wished for the exposure that we were getting, and the speed at which we did stuff. Our place was suddenly the fast-moving and happening place with noise all the time, customer demos, calls and meetings, whiteboards and improvement plans. And from there it only went on to become better and with our team getting VCons and other infrastructural and visible changes, things just got better.How it worked with my daughter:Trying to convince her to try different foods normally came back with ‘Yuk’ or ‘No’. One day, I told her that from now she has to eat regular food like everybody else, and there would be nothing special for her. To her 5-year-old mind, it sounded more like wartime, and she took the challenge well. She starved herself for 2 days and finally, she won.When your stakeholder decides to not cooperate, it is tough to get things moving, and if it is time-critical and you have a lot at stake, you might not be able to take tough calls.How Phased approach worked in my project:I was also part of a team which did phased transformation. This was a newly formed team which was just starting its journey in the project. We started 2 weeks’ sprints with just a daily stand-up and Ad hoc assignment of stories from a well-kept backlog which was managed by the PO. No training was conducted, except a 30-minute training on the ALM tool essentials.In this phased implementation approach, we (few people who knew Agile) observed the team and based on their feedback introduced ceremonies. Team members brought in the role called scrum master (though they just called him a lead for all issues and coordination). The team members were all new and they required guidance before they could commit to any story and also to confirm if what they did was right, by the end of the first sprint we scheduled in Product Grooming and demo sessions. Sprint planning and Sprint backlog came only in the 3rd sprint, till then the team just took all they could.Retro was again suggested by the team not as a regular meeting, but as a monthly meeting to see what we should do differently, as the teams now saw that their suggestions were acted on, they were more than happy to suggest a formal meeting to have best practices added in. And all of a sudden in just 3 sprints we had all elements of Scrum. Team members were driven and self-organizing and they never wanted to go back to any traditional model for project execution.How Phased approach worked with my daughter:I started really small – tomatoes on pizza, and she liked it; then potatoes with rice, she liked it, cucumber salad also was welcome. But the problem with phased implementation plan at my home is that it went with a high degree of resistance and blackmailing, she knew that she had a fallback option. But she was not starving and that was a relief. But I really never managed to add much to her menu. She had her staples and even after almost 2 months, we just have around 5-6 more veggies added into the list.In both cases, my teams became Agile – At first with a lot of resistance but they were the perfect textbook Agile and they knew the whys and the direction. In the second, teams learned from their mistakes and brought in best practices until they were Agile. Here, only a push in the right direction by Agile experts/scrum master was required.We always knew the direction in both cases, it was just about who drove and at what pace.
Rated 4.0/5 based on 3 customer reviews
Big Bang and Phased approaches – How to do it, and what to expect?
Blogs
112
Big Bang and Phased approaches – How to do it, a...

The three most popular frameworks for organization... Read More

A Perspective Of Project Management And Product Management

For those who have had experiences working as a project manager, the concepts and activities of project management come very natural. Project management practices have been around since ancient times. As early as 2570 BC, there were records of project managers doing the planning, coordination, and construction for the Great Pyramid of Giza. The history of modern Project Management is said to have started around 1950. Today, it is largely popularised by accredited bodies such as the Project Management Institute (PMI®️) - Project Management Body of Knowledge, PRINCE2®️, etc. Interesting things to know about Product Management  Product management came as a more recent development. It was started by Neil McElroy in 1931 as a memo written to justify the hiring of more product managers. In recent years, product management had been infiltrating the Infocomm and Tech industry through the development of methodologies such as Scrum and Agile Manifesto. Comparing the two roles and practices, there are often misconceptions that Product Management and Project Management are interchangeable terms. That is to say, a Project Manager role is similar or interchangeable with a Product Manager role. Project Management vs. Product Management Perspective Let’s try to identify the differences between the two by first looking at the definitions of Project Management and Product Management. How does “project” differ from “product”? The term “Project” as defined by PMI’s guide to the Project Management Body of Knowledge is- “A temporary endeavour undertaken to create a unique product, service or result. A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources.” Whereas the term “Product” refers to- “A service or an item offered for sale in the market. The value of a product depends on the market, the quality, the marketing and the segment of audiences that is targeted. Each product has a lifecycle after which it needs replacement or upgrade of features.” From the above definitions, a project and product are different. For illustration purposes, a project is similar to someone performing a “task”. The task is bound by a timeframe and has a defined scope and resources. A product, on the other hand, is the output of the project or task. It is like the goods or services produced as the output to the work performed on the task.Which is better - Project or Product Management?It is very difficult to tell. But having both the Product Manager and the Project Manager at the team level will contribute to the successful completion of product in a positive way. It is not about choosing the best. Both the Project Manager and Product Manager are equally important for yielding a long-term business success.Let us now explore further into the roles and responsibilities of Project Management and Product Management.Comparison of Project and Product Management According to Blackblot Product Manager’s Toolkit (PMTK) Methodology, “Product Management is an occupational domain which contains two main disciplines. They are the- a) Product Planning andb) Product Marketing. Product Planning is focused on knowing the customers well and being the advocacy of the customer. It is an ongoing process of identifying and articulating market requirements that defines a product’s features set. Product Marketing is about knowing the business value of the product. They refer to activities aimed at generating products awareness, product differentiation and demand.” In the same context, PMI’s definition of Project Management refers to “the application of several techniques, skills, knowledge and tools to ensure that the project is able to meet the requirements.”Therefore, there are even more distinct differences between the project and product manager in terms of roles and responsibilities of a Project Manager as compared to that required for a Product Manager. The Product Manager’s role is focused on delivering value and increasing the intrinsic value of the product. To do these, the Product Manager need to get to know the users of the product well. Also, the Product Manager should take on the roles of a business analyst in articulating and defining the requirements to the product team. He/She should also be a marketing specialist to promote the product and be responsible for driving usage and awareness. An important role of the Product Manager is also determining which features to roll out first and the time-to-market for the product. These skills are even more relevant in an Agile environment where there are multiple software releases and the role of a product manager is important in ensuring that the team is “building the right product”. Lets see the comparison between the Project and Product management in the tabular form. A Project Manager’s responsibilities is to organise the team to deliver the project requirements within the approved budget and resources given. The Project Manager is focused on the process and the application of the right tools and method to complete the predefined task or assignment within a certain timeframe. The Project Manager role is to ensure that the team is “building the product right”.Hence in summary While transitioning from the project manager role to product manager, you need to keep one thing in mind-A Project Manager’s role is to ensure that the team is ‘building the product in a right way’. Whereas, a Product Manager’s role is to ensure that the team is ‘building the right product’. In essence, a Product Manager should work closely with a Project Manager to ensure better synergy and success in the implementation of the project or product. The project management and the product management roles do not overlap one another, but complement each other.  Both perform different functions and work hand-in-hand to ensure the delivery and success of the implementation of a project or product.
Rated 3.5/5 based on 0 customer reviews
A Perspective Of Project Management And Product Management
Blogs
478
A Perspective Of Project Management And Product Ma...

For those who have had experiences working as a pr... Read More