Search

The Three Most Fundamental Aspects of Project Management

Over the years I have found that my most popular blog posts are those that speak to entry-level project managers. They value information which is clear and concise and which helps them understand what tools and techniques to use. Project management is a vast practice area and for somebody who has only recently started managing projects, it can seem overwhelming. It is my observation that there are more entry-level project managers coming into the field. And there is a good reason for that. With more and more changes taking place at a faster rate, we have a need for more people to manage those changes. This can be anything from integrating new technology to streamlining business processes or producing cheaper and better consumer goods. With that being said, let’s look at the three most fundamental project management tools and techniques that will help entry-level project managers get their project off the ground.Project DefinitionProjects need to be defined and scoped before they are planned and executed. That is true for all projects irrespective of the type of methodology they use. Defining the project helps us understand what it is meant to deliver, what the benefits are, what the costs might be and by when it is needed. This may sound like a plan to you, but it’s more like a high-level description of the project without the details having been fleshed out. The main question we ask during project definition is whether the project is worthwhile doing or not. There may be lots of ideas for new projects but not all of them have a good business rationale. Therefore they shouldn't be executed at this moment in time with this particular scope. In the company where you work, I’m sure there are many things you could improve on and many ways in which you could enhance your products or services. But not all of these enhancements will be viable business ideas, perhaps because there is a small market for some of those products or too low a margin.When we define the project, we’re essentially looking at the project’s business case and ascertaining if it provides a strong enough foundation for the project to go ahead. Defining the project can take as little as a couple of days for a very small project and several months for a larger one. You can capture the conclusion of this phase in a Project Definition Document, Project Charter, Terms of Reference or Business Case. Different companies use different terms for this document, but they may essentially contain the same information. What I recommend you to put in the document is: Aims and objectives of the project, high-level deliverables, expected benefits, high-level constraints, assumptions and risks, expected costs, future revenues, expected end date, name of project sponsor, project manager, and core team members.Milestone plan  Once the project has been approved, meaning that the Project Definition Document has been signed off, you can move to the next part of the project, which is to plan it. The way you plan a project and lay out its phases, stages, and milestones will look a bit different depending on the methodology your company prefers. If you’re in a more traditional waterfall environment you’d be planning the project in a sequential way, beginning with requirements gathering and detailed statements of scope. You’d then plan for the build or execution phase to take place followed by some testing and final delivery or implantation. And of course, you’d plan for a project review to take place at the end. In more agile environments you’d carry out the above activities (requirements gathering, build, test, deliver, and review) in much shorter intervals or iterations. In addition, you’d deliver something tangible after each phase or iteration instead of all products or features being delivered at the end, which is what we do with a waterfall methodology.No matter how you plan your project, it’s a good practice to plan it collaboratively with the team. Those days are over where the project manager was sitting in isolation behind their desk doing all the planning. That approach simply doesn't create buy-in from the team members. They want to be involved in planning the work that they are expected to carry out.There are several collaborative planning techniques out there that you can make use of. I favour an old-fashioned post-it note-approach where you get people together and brainstorm what the phases, work streams and milestones of the project might look like. You’ll need lots of post-its and a white board or a wall to stick the notes onto. You also need a good facilitator (perhaps your good self) who can guide the team through the process. At the end, you should have a rough idea of which milestones and outputs will be delivered by when. You should also assign ownership to each milestone or deliverable as otherwise, the project manager may end up owning most of the items. Ask the owners to carry out the detailed planning of their individual items and revert at the next meeting with a confirmation of exactly what will be delivered by when. If your team is remote you can make use of virtual post-it-note planning tools.The outcome of your collaborative meetings and planning activities can be captured in a milestone plan. This would be a simple Excel sheet listing the project’s top ten milestones, the owner of each milestone and the expected delivery date. Very simple! As a project moves forward you can also use the spreadsheet to record whether each milestone is on track for delivery and comment on their status. In that way, this simple one-pager overview of milestones becomes a high-level plan and a tracking tool in one. This is an ideal overview sheet to use as a communication tool to your stakeholders so that they can ascertain the status of the project. Your stakeholders don’t need a detailed plan. An overview of the top ten milestones will be sufficient. The detailed plan is reserved for the core team.Risks listBe warned that no matter the size, complexity or methodology of your project, I can assure you that it will be full of risks. That’s because all projects are about creating change, meaning that the project will result in something that hasn’t been done before in that exact setting. In other words, every project is unique and therefore contains a certain element of risk. Project management methodology is essentially there to control risk and to help us execute a project with some level of predictability in spite of its uncertain elements. Defining a project, identifying and analysing user needs and requirements, planning how these requirements will result in outputs and deliveries, clarifying roles and responsibilities and prototyping the solution are all examples of activities we undertake in project management with the aim of driving down risk.Managing risks is a dynamic process as the project’s environment changes on a daily basis. Identifying and mitigating risks is, therefore, something which shouldn’t just be done when the project starts up. It’s an essential project management activity that should be carried out on a regular basis to make sure that new risks are identified and managed and that the existing ones are reviewed. In essence, I suggest that you sit down with your team every couple of weeks to go through the risk list. The collaborative element is important, as the project manager cannot identify all the risks on her own. The team has the knowledge, not only of the things that could go wrong but also in terms of generating ideas for how to overcome potential roadblocks.The outcome of the collaborative risk management meetings is risk list. This is a simple Excel tool, which lists and describes all the risks, the date they were logged, what the potential impact of the risk is and how it can be mitigated. The risk list should also contain information about the probability and likelihood of each risk (high, medium, low) as well as an owner. In many projects, there is a tendency that the project manager ends up owning most of the mitigation strategies. But in many cases, a team member or a stakeholder is the best person to manage a specific risk because they are closer to the detail.In summaryProject management tools and techniques can be difficult to navigate for an entry-level project manager. Three of the most important tools for a project manager to make use of on any project are: a Project Definition Document, a Milestone Plan and a Risk List. Whereas the project manager owns all of these tools, it’s not sufficient to simply fill them in on their own. Irrespective of whether we are running an Agile, Waterfall or a hybrid project, it will be the collective effort of the people involved who will get the project delivered. For that reason, the tools we use must be as collaborative as possible so that we can make the most of our precious team.
Rated 4.0/5 based on 1 customer reviews

The Three Most Fundamental Aspects of Project Management

391
The Three Most Fundamental Aspects of Project Management

Over the years I have found that my most popular blog posts are those that speak to entry-level project managers. They value information which is clear and concise and which helps them understand what tools and techniques to use. Project management is a vast practice area and for somebody who has only recently started managing projects, it can seem overwhelming. It is my observation that there are more entry-level project managers coming into the field. And there is a good reason for that. With more and more changes taking place at a faster rate, we have a need for more people to manage those changes. This can be anything from integrating new technology to streamlining business processes or producing cheaper and better consumer goods. With that being said, let’s look at the three most fundamental project management tools and techniques that will help entry-level project managers get their project off the ground.

Project Definition

Projects need to be defined and scoped before they are planned and executed. That is true for all projects irrespective of the type of methodology they use. Defining the project helps us understand what it is meant to deliver, what the benefits are, what the costs might be and by when it is needed. This may sound like a plan to you, but it’s more like a high-level description of the project without the details having been fleshed out. The main question we ask during project definition is whether the project is worthwhile doing or not. There may be lots of ideas for new projects but not all of them have a good business rationale. Therefore they shouldn't be executed at this moment in time with this particular scope. In the company where you work, I’m sure there are many things you could improve on and many ways in which you could enhance your products or services. But not all of these enhancements will be viable business ideas, perhaps because there is a small market for some of those products or too low a margin.

When we define the project, we’re essentially looking at the project’s business case and ascertaining if it provides a strong enough foundation for the project to go ahead. Defining the project can take as little as a couple of days for a very small project and several months for a larger one. You can capture the conclusion of this phase in a Project Definition Document, Project Charter, Terms of Reference or Business Case. Different companies use different terms for this document, but they may essentially contain the same information. What I recommend you to put in the document is: Aims and objectives of the project, high-level deliverables, expected benefits, high-level constraints, assumptions and risks, expected costs, future revenues, expected end date, name of project sponsor, project manager, and core team members.

Milestone plan  

Once the project has been approved, meaning that the Project Definition Document has been signed off, you can move to the next part of the project, which is to plan it. The way you plan a project and lay out its phases, stages, and milestones will look a bit different depending on the methodology your company prefers. If you’re in a more traditional waterfall environment you’d be planning the project in a sequential way, beginning with requirements gathering and detailed statements of scope. You’d then plan for the build or execution phase to take place followed by some testing and final delivery or implantation. And of course, you’d plan for a project review to take place at the end. In more agile environments you’d carry out the above activities (requirements gathering, build, test, deliver, and review) in much shorter intervals or iterations. In addition, you’d deliver something tangible after each phase or iteration instead of all products or features being delivered at the end, which is what we do with a waterfall methodology.

No matter how you plan your project, it’s a good practice to plan it collaboratively with the team. Those days are over where the project manager was sitting in isolation behind their desk doing all the planning. That approach simply doesn't create buy-in from the team members. They want to be involved in planning the work that they are expected to carry out.

There are several collaborative planning techniques out there that you can make use of. I favour an old-fashioned post-it note-approach where you get people together and brainstorm what the phases, work streams and milestones of the project might look like. You’ll need lots of post-its and a white board or a wall to stick the notes onto. You also need a good facilitator (perhaps your good self) who can guide the team through the process. At the end, you should have a rough idea of which milestones and outputs will be delivered by when. You should also assign ownership to each milestone or deliverable as otherwise, the project manager may end up owning most of the items. Ask the owners to carry out the detailed planning of their individual items and revert at the next meeting with a confirmation of exactly what will be delivered by when. If your team is remote you can make use of virtual post-it-note planning tools.

The outcome of your collaborative meetings and planning activities can be captured in a milestone plan. This would be a simple Excel sheet listing the project’s top ten milestones, the owner of each milestone and the expected delivery date. Very simple! As a project moves forward you can also use the spreadsheet to record whether each milestone is on track for delivery and comment on their status. In that way, this simple one-pager overview of milestones becomes a high-level plan and a tracking tool in one. This is an ideal overview sheet to use as a communication tool to your stakeholders so that they can ascertain the status of the project. Your stakeholders don’t need a detailed plan. An overview of the top ten milestones will be sufficient. The detailed plan is reserved for the core team.

Risks list

Risk Management Lists


Be warned that no matter the size, complexity or methodology of your project, I can assure you that it will be full of risks. That’s because all projects are about creating change, meaning that the project will result in something that hasn’t been done before in that exact setting. In other words, every project is unique and therefore contains a certain element of risk. Project management methodology is essentially there to control risk and to help us execute a project with some level of predictability in spite of its uncertain elements. Defining a project, identifying and analysing user needs and requirements, planning how these requirements will result in outputs and deliveries, clarifying roles and responsibilities and prototyping the solution are all examples of activities we undertake in project management with the aim of driving down risk.

Managing risks is a dynamic process as the project’s environment changes on a daily basis. Identifying and mitigating risks is, therefore, something which shouldn’t just be done when the project starts up. It’s an essential project management activity that should be carried out on a regular basis to make sure that new risks are identified and managed and that the existing ones are reviewed. In essence, I suggest that you sit down with your team every couple of weeks to go through the risk list. The collaborative element is important, as the project manager cannot identify all the risks on her own. The team has the knowledge, not only of the things that could go wrong but also in terms of generating ideas for how to overcome potential roadblocks.

The outcome of the collaborative risk management meetings is risk list. This is a simple Excel tool, which lists and describes all the risks, the date they were logged, what the potential impact of the risk is and how it can be mitigated. The risk list should also contain information about the probability and likelihood of each risk (high, medium, low) as well as an owner. In many projects, there is a tendency that the project manager ends up owning most of the mitigation strategies. But in many cases, a team member or a stakeholder is the best person to manage a specific risk because they are closer to the detail.


In summary

Project management tools and techniques can be difficult to navigate for an entry-level project manager. Three of the most important tools for a project manager to make use of on any project are: a Project Definition Document, a Milestone Plan and a Risk List. Whereas the project manager owns all of these tools, it’s not sufficient to simply fill them in on their own. Irrespective of whether we are running an Agile, Waterfall or a hybrid project, it will be the collective effort of the people involved who will get the project delivered. For that reason, the tools we use must be as collaborative as possible so that we can make the most of our precious team.

Susanne

Susanne Madsen

Blog author

Susanne Madsen is an internationally recognised project leadership coach, trainer and consultant. She is the author of The Project Management Coaching Workbook and The Power of Project Leadership. Working with organisations globally she helps project managers step up and become better leaders.

Prior to setting up her own business, Susanne worked for almost 20 years in the corporate sector leading high-profile programmes of up to $30 million for organisations such as Standard Bank, Citigroup and JPMorgan Chase. She is a fully qualified Corporate and Executive coach, accredited by DISC and a regular contributor to the Association for Project Management (APM).

Susanne is also the co-founded The Project Leadership Institute, which is dedicated to building authentic project leaders by engaging the heart, the soul and the mind.

Leave a Reply

Your email address will not be published. Required fields are marked *

Comments

Sukran

Consulting is good for the fresher visiting this site .thanks m really interested in it program.

Suggested Blogs

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 Ma...

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

10 Characteristics Of a Good Project Manager

Good leaders are hard to find, but great project managers are rarer still – What a great saying! Well, it has its own worth acknowledging that to find a reliable, and successful project manager in the current era is like finding a true pearl inside the sea shell. Being a project manager is a specific kind of leadership position, which requires certain character traits and qualities. If we ask you, do you have any general idea about a good project manager, a single point you can define them would be – they delivers projects within the deadline and budget set by the clients, meeting or notwithstanding surpassing the desires of the partners, right? It’s not enough. Actually, it takes more to become a good and idol project manager to whom someone could admire. In this article, we are going to highlight some striking traits and qualities of a Good project manager which can help you become a better one or to improve yourself.Time Management techniques helps you to assign correct time slots to activities as per their importance. The right allocation of time to the right task in order to make the best possible use of time refers to time management. Top 10 Qualities to become a Successful Project Manager 1.    They Inspire a Shared Vision An effective project leader is often described as having a vision of where to go and the ability to articulate it. A leader or project manager is someone who lifts you up, gives you a reason of being, and gives the vision and spirit to change. The visionary project managers enable people to feel they have a real stake in the project. Moreover, they empower their team mates to experience the vision of their own and offer other the opportunity to create their own vision, to explore what the vision will mean to their jobs and their lives, as well as to envision their future as part of the vision of their organization. 2.    They are a Good Communicator According to Jada Pinkett Smith, a slogan of every good project manager is; “My belief is that communication is the best way to create strong relationships” Another strong trait that distinguishes a good project manager from others is, their ability to communicate with people at all levels. Since, the project leadership calls for clear communication about responsibility, goals, performance, expectations, and feedback – a good project manager can be said a complete package comprising all these qualities. The pioneer must be able to successfully arrange and utilize influence when it’s important to guarantee the accomplishment of group and venture. How it comes about gainful? Successful correspondence brings about group accomplishments by making express rules for professional success of cable car individuals. 3.    Integrity One of the most important things any project manager should always keep in their mind is, it takes their actions to set a particular modus operandi for a team, rather than their words. A good management demands commitment and demonstration of ethical practices. The leadership or project management depends on integrity represents set of values, dedication to honesty, and consistency in behaviors with team mates. Integrity is that a good project manager takes responsibility for setting the high bar for ethical behaviors for oneself, as well as reward those who exemplify these practices. Leadership motivated by self-interest does not serve the wellbeing of a team. 4.    They Possess Leadership Skills If you want to become a successful project manager, you ought to own good leadership skills. Project managers must also deal with teams coming from various walks of life. Hence, it winds up noticeably basic for them to rouse workers and calibrate group execution to achieve organizational goals through various leadership styles. A great project manager sets the tone for the project and provide a clear vision about its objectives for the team. A feeling of foreknowledge helps also – by foreseeing potential issues, you can have your group prepared to solve them in the blink of the eye. Enthusiasm and passion are two key elements you should adopt, if you want to make people follow you—nobody will do so if you’re sporting a negative attitude. 5.They are Good Decision Maker Good decision making skill is not only crucial for personal life but it also very important in professional life as well. The good project managers are empowered to make countless decisions which will help define the project track. As we all know that a single minor wrong decision taken can easily jeopardize the entire project. Thus, a project manager needs to be capable of thinking quickly and reacting decisively. 6.    Expert in Task Delegation Task delegation is another basic skill in you which you need to be expert in. You should be able to judge your team members’ skills and assign the tasks in accordance with their strengths. Being a pioneer doesn’t imply that you have to consider each minor little detail of a venture. Show your team members you trust them and delegate tasks to them. 7.    They are Well Organized Henry Mintzberg said; “Management is, above all, a practice where art, science, and craft meet” Good organization is a key factor for creating a productive work environment as well as solving problems under pressure. Being well-organized helps to stay focused on the big picture and to prioritize your own tasks and responsibilities. With regards to exhibiting your outcomes, you ought to have the capacity to recuperate all the important information and demonstrate an intelligible vision of a venture to be executed. 8.    They Own Proficiency Proficiency and thorough knowledge – they both can be said a basic yardsticks on the basis of which a leader’s or manager wisdom or excellence can be weighed. Being on top of your projects entails a vast amount of industry knowledge to be effective in what you do. Some learning on the money related and legitimate side of your tasks won’t hurt either. You should be seen as able and skilled by your group. 9.    They are Great Problem Solver! The good project managers work with a team of experts or consultants and use their mastery of handling issues in most effective ways. Nobody will anticipate that you will have a prepared answer for every single issue; you should have the capacity to utilize the knowledge of your team members and even stakeholders to produce a collective response to any problems you experience on your way to delivering a project. 10.    They know what is Collaboration This is the last, and the most important trait that should exist within every good project manager or leader. A grip of group progression is fundamental on the off chance that you need your group to work easily on your ventures. When building up your group, remember this: contentions and contradictions will undoubtedly happen; as a pioneer, you’ll should have the capacity to intervene them and ensure all you colleagues progress in the direction of a similar objective.  
Rated 4.0/5 based on 2 customer reviews
1289
10 Characteristics Of a Good Project Manager

Good leaders are hard to find, but great project m... Read More

Role of Float, Leads, and Lags in developing Project Schedule

Introduction This article discusses scheduling terminologies (Float, Leads, and Lags) which are commonly used for developing project schedule and followed by examples for fundamental understanding. This article is developed on the premise that the reader is having a basic understanding of project schedule network diagram, sequencing of activities, and logical relationships between the activities (e.g. Finish to Start, Start to Start, Finish to Finish, and Start to finish). This article is useful to PMP exam aspirants and to practitioners for developing robust project schedule and execute it accordingly. Float, Leads, and Lags are very simple to understand and to apply in our project schedules. However, lack of appropriate knowledge can lead Project Manager (PM) to develop an inferior quality of project schedules and ultimately result in an ineffective execution of it. Conceptual Understanding: Precedence Diagramming Method When it comes to the management of project schedules, the precedence diagram method helps PM to determine project activity flow. This flow of activity helps evaluate logical relationships or dependencies between the various project activities. That also includes evaluating relationships or dependencies between two dependent activities. The concept of Leads and Lags is critical in defining and evaluating these relationships. Leads and Lags worked as modifiers of these relationships or dependencies. Refer the below figure for Precedence Diagramming Method Relation Types.   Float Among many project scheduling concepts, Float is one of the key concepts that represents the flexibility of the project schedule. Flexibility in terms of delaying or advancing the project activities. Float simply means freedom or breathing time available in the schedule for PM for executing the project activities. To understand this concept, refer the below-given example. Activity A = 3 Days, Activity B = 2 Days, and Activity C= 3 Days. These activities are having Finish to Start Relationships. That means, when Activity A will finish, B will start and when B will finish, activity C will start. That means Activity C is dependent on the completion of Activity A and Activity B. In the example given below, let's assume that Activity B is a complex activity and PM has kept 2 days of float to avoid failure of the overall project schedule. Here, this 2 days’ Float will work as an additional time or breathing time or freedom available to complete Activity B in case any undesired situation’s impacts on the execution of it. Please refer below-given illustrations for detailed understanding.   As shown in the illustration, let’s discuss the various scenarios of using this Float or additional time for executing Activity B and its impact on the successor Activity A and C. Scenario 1: Start of Activity B immediately after finishing of Activity A Let's assume that PM has decided to start the Activity B immediately after the completion of Activity A i.e. ES of activity B. If Activity B is completed in 2days as planned, then PM will be left with 2 days of freedom or breathing time. In this case, PM can choose-  To use 2 days of free time by advancing Activity C. i.e. ES of activity C and complete the project 2 days earlier (8 days) than planned (10 days) i.e. EF of Activity C or To do nothing and to wait for Activity C to start at its planned start time and to complete the project as planned (10 days). Scenario 2: Delaying Activity B after Finishing Activity A. After finishing Activity A, PM reviewed the work progress and found that the project activities are in control. PM chooses to delay the Activity B by 2 days after completion of Activity A. i.e. LS of Activity B. However, in this scenario, PM should have high confidence to complete the Activity B within its planned time of 2 days. Failure in finishing Activity B in 2 days will delay the Activity C and that ultimately may result in the delay of overall project schedule. Scenario 3: Mixed Scenario If the project activities are in control, PM can also choose to delay Activity B by 1 day i.e. LS of Activity B after the finishing of Activity A. If Activity B finishes in 2 days, then PM will be left with 1 day of float. PM can choose to advance the Activity C by 1 day i.e. ES of Activity C and finish the project 1 day earlier (9 days) or PM can choose to do nothing and wait for Activity C to be started at its planned start time. Leads and Lags Now, let’s understand this concept in detail. Leads and Lags are nothing but the type of floats (Freedom). Lead It is an activity relationship where successor activity is advanced in order to be conducted parallel to predecessor activity. That means the predecessor activity is still running and successor activity initiates. Let’s understand the below-given example. Let us assume Activity A and Activity B has Finish to Start relationship. It takes 1 day to write 2 pages of report. Therefore, estimated time for finishing Activity A (Write a 12-page report) = 6 days. It takes 1 day to review 3 pages of report. Therefore, estimated time for Finishing Activity B (Review 12-page Report) = 4 days. Therefore, for completing this project Activity A and B (Finish to Start relationship), PM will need 10 days. However, if PM chooses to advance the Activity B and start reviewing the completed pages of report from the 4th day of Activity A, then PM will be able to complete the project (Activity A & B) in a total of 7 days. In a nutshell, when the predecessor activity is still running and successor activity starts, this is called Lead. The remaining time of Activity A when the Activity B starts is called Lead Time, or basically, the overlap time between Activity A and B is called Lead time. In the above example, Lead Time is 3 days. This concept is applied as Fast Tracking technique for compressing the schedule. Lag It is an activity relationship where the successor activity is delayed to pass some time right after the completion of its predecessor activity. Lag describes delay or addition of time. Let’s understand the below-given example. Let us assume Activity A and Activity B have Finish to Start relationship. It takes 1 day for plastering the wall. Therefore, estimated time for finishing Activity A = 1 day. It takes 1 day for painting the wall. Therefore, estimated time for finishing Activity B = 1 day.   Considering this scenario, PM will need 2 days for finishing this project Activity A and B. However, we cannot paint the wall until the cement plaster is set up and dried. Therefore, there will be a need of putting a mandatory delay after completing the Activity A to allow cement plaster to be set up.  Let us assume that PM chooses to put a lag of 1 day after finishing Activity A. In this case, PM will require 3 days to finish the project (Activity A and B). In a nutshell, when predecessor activity finishes and if there is a need for delay or waiting period prior to starting the successor activity, then this is called Lag and the delay period is called Lag time. In the above example, Lag Time is 1 day. Here it is quite worth to note that PM does not put lags in the project schedule without any proper justification as no one wants to delay the project. So, Lags should always be considered to satisfy some predefined requirement, condition, or strategic objective of project.  
Rated 4.0/5 based on 20 customer reviews
Role of Float, Leads, and Lags in developing Proje...

Introduction This article discusses scheduling ... Read More

other Blogs