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.

The Three Most Fundamental Aspects of Project Management

1K
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.

Join the Discussion

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

1 comments

Sukran 09 Jun 2018

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

Suggested Blogs

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 belowTask IDMile stoneSummary tasksSub tasksDuration Resource.......1RS302Feature 1Elicit requirementsDocument requirement.......Feature 2....................FSFeature 1GUIBusiness logic.......Feature 2............Design........As 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.Task IDMile stoneSummary tasksSub tasksDurationResource1Release 1......2Feature 1RS related tasksOther task from sprint backlogOther task from sprint backlogFeature 2..................Release 2Feature 3GUIBusiness logicOther task from sprint backlogFeature 4............Release 3......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.
2313
How are Changeless Principles Responsible For Proj...

IntroductionNo other industry perhaps is character... Read More

Project Manager Salary Guide 2021

Project management skills and expertise are in demand globally, and earning potential remains promising. The Project Management Institute (PMI)regularly runs a salary survey to find out what kind of salary project managers draw across industries and across geographies. This is probably one of the most comprehensive salary surveys conducted for any job type. Earning Power: Project Management Salary Survey—Eleventh Edition (2020), the latest salary survey from the Project Management Institute (PMI) equips practitioners with the most comprehensive view of project managers’ earnings from 42 countries around the world.  Greater awareness of how skill level, experience and certifications impact salary can give practitioners considerable earning power in a dynamic job market. And this critical data can help recruiters, human resources and compensation professionals establish fair and equitable salaries for project management roles within their organizations. Some of the data you will discover in this PMI report might surprise you. In this article, we give you the complete lowdown on the findings of the survey.Data gathered The scale of the PMI salary survey is vast: over 32,000+ project managers across industries and verticals, across the globe. This sample size is a good representative of the population and provides a realistic representation of salary figures. Quite a wide variety of information is collected by PMI’s team – position, years of PM experience, highest formal education, degree in project management, PMP® status, training per year, type of project, avg team size, project budget, and many more – from the sample size from each of the 42 countries. The report is of about 360 pages long, with quite a detailed information segregated by countries.One can thus slice and dice the figures to extract an amazing amount of insights into how project management in general and PMP certification can impact the salary of employees across industries, verticals, positions, and geographies. The top3 countries The top 3 countries on median salary figures were: Switzerland ($132,086) United States ($116,000) Australia ($101,381)The verdict “There’s never been a better time to be a project manager”, states the PMI Salary Survey, Eleventh Edition (2020).But what the report truly indicates is that there has never been a better time to be a PMP® certified project manager. The final verdict? Here it is: Respondents with PMP® certification report 22% higher median salaries than those without PMP® certification. Project Manager salary ranges Candidates with a PMP certification are prioritized over non-certified candidates. They are also more likely to get better compensation. However, the median salary depends on several factors such as their country of residence, years of experience, position or role and the average size of projects managed, including average project budget and average project team size. Project Manager salaries by countryCountriesMedian SalaryUSA$116,000India$28,750Singapore$71,279Hong Kong$76,607United Arab Emirates$81,665Project Manager salaries by years of experienceYearsUSAIndiaSingaporeHong KongUnited Arab Emirates
6563
Project Manager Salary Guide 2021

Project management skills and expertise are in dem... Read More

Project Management: What’s Trending in 2021

Project management is the practice that is used to initiate, design, execute, control, and close a team's work in order to reach specific objectives and fulfil specific success criteria at the specified time. The main challenge of project management is to achieve all project objectives within the given limits.A decade ago, managing projects was difficult and challenging. It was difficult to set clear goals with less project management tools and projects were being managed by smaller teams with simpler projects.Fast forwarding to 2020, the scenario is completely different as Project Management seems like a phoenix rising from the ashes. The teams are no longer small, nor are the tasks, and the goals are defined with a proper system.The project management industry is quickly evolving, keeping pace with advanced technologies, tools, and the latest trends.Today, we will discuss the top 5 Project Management global trends in 2020.1. Artificial Intelligence (AI) & Automation Will Impact ProjectsArtificial Intelligence has had a very positive impact on projects. According to a PMI report, software development, aerospace, healthcare and financing all implement Artificial Intelligence in their way of managing projects.The first thing project managers need to do is take AI into account in project management and then learn how to utilize it for successfully completing projects.Using AI in automating data will make it easier to handle projects than before. Moreover, you can form positive business relationships with your team members and clients, resulting in proper coordination and transparency.It’s quite common to witness poor estimates and unknown external factors pushing the deadline. Artificial intelligence can calculate the duration, cost and progress of a project properly and predict realistic project schedules.2. More Project Managers Will Incorporate Hybrid Project ManagementEvery project is created differently and differs in methodology and execution. No wonder the concept of hybrid project management is becoming increasingly popular and with every passing day, many Project managers and Scrum masters are combining more than one methodology.According to PMI reports, Hybrid project management aims to combine standard project management techniques with the agile methodology.When the hybrid model, such as combining a traditional approach is implemented with an Agile process, team members from different points of view and work styles will collaborate and achieve more flexibility, dedication, and productivity in their own way.Project managers are inclining to this flexible approach of projects in the current year. A combination of agile and traditional methodologies is best suited in a multi-project environment, where complex parts are executed using agile, and a traditional method is used for the simpler parts.3. Managing Projects Will Become Easier with Emotional Intelligence (EI)It seems strange, but project success is related to humans understanding and realizing emotions. How? According to PMI.org emotional intelligence can strongly predict performance no matter what job you do. It allows clients, team members, sponsors and management to interact with each other with clarity, handle challenges efficiently and make committed choices to act strategically and swiftly. EI is now an essential technology for a successful business outcome.Understanding the emotions of the team members and dealing with different personalities ensures that the project keeps progressing at a smooth and constant pace. This is an invaluable leadership ability for project managers around the world.Therefore, it becomes more important than ever to learn about emotional intelligence and what drives people to predict future project success.4. Remote Working is on the RiseThe trend of working remotely is now extremely common and this will go on in future too. There are a lot of advantages when people work remotely. It offers more flexibility and saves a lot of time as you don’t need to travel to your workplace. The costs to the project and company get further reduced leading to the development of talent. According to the results of a survey by Wrike, 83% of respondents work remotely every day for at least one to two hours. 43% of them reported that they work remotely now, more than they did a couple of years ago.When working remotely, projects will be managed by:Setting up daily, stand-up meetings and calls to stay updated on the progressHaving your team members keep you updated on any project changes or updatesUsing online collaboration tools such as Microsoft Planner to collaborate with team members and never miss out on any changes or updatesDoing quarterly individual assessments in a yearThe future of project management will witness a steep rise in next-gen project managers, project management offices, and more focus stepping up cybersecurity. Project managers should pay attention to these trends to successfully lead their teams.5. More Jobs Will be Available for Project ManagersProject managers are involved in every possible industry. According to ‘The Project Management Institute (PMI) report’ last year, the project management labour force is predicted to grow by 33 percent in over 11 countries by 2027. There will be a wide range of jobs for project management and these are estimated to grow over the next 10 years. Some of them are in industries like: Management and Professional ServicesManufacturingFinance and InsuranceInformation Services and PublishingConstructionUtilitiesOil and GasBy 2027, nearly 88 million professionals will be required in project management-oriented roles. The first in the race to hiring are China and India forming more than 75 percent of the total project management-oriented employment.The report further stresses that project managers are key in delivering successful projects and products. Acting otherwise can potentially create loss of nearly US$208 billion in GDP over the 10 years in the 11 countries examined.With the new trends of 2020, project management will be playing a major role in fastening product development with its new technologies, and in turn, increasing workflow efficiency. Owing to its exponential growth, multiple job opportunities will be created and staying on top of the latest trends will give one the leverage to make the most of such changes.
9340
Project Management: What’s Trending in 2021

Project management is the practice that is used to... Read More

Useful links