Search

5 Best Techniques for Project Management

Project management techniques are required to list the steps involved in a project and how to accomplish each step in order to achieve the final goal. In this article, we’re going to discuss five project management methodologies that are available in the market at present and used by various organizations. 1) Agile Methodology Agile is one of the most widely used project management methodologies in the market right now. One of the main reasons why it is popular is its ‘sprint principle’. In this, changes can be made to the plan at any stage. The client or the development team can suggest the changes if any, and it can be implemented in the main plan. This provides flexibility to the developers, especially when working on large-scale projects. Another important feature of Agile is that it contains teams that consist of few members. This helps team members to plan and work well. The meetings that are held in organizations that follow Agile methodology are also short. It lasts for less than 10 minutes wherein the team only discusses three concepts – how much work was done? What’s the next step? What are the possible hurdles in the next step? 2) PRINCE2 PRINCE stands for PRojects IN Controlled Environments. It was initially used for government projects and later adopted by the private sector. The principles of PRINCE2 are standard such that it can be implemented in any organization around the world. The position and the description of each position are clearly defined in order to avoid confusions in the process. The core plan is divided into smaller plans in order to get the work done faster. 3) Waterfall Methodology This is one of the oldest project management techniques that is used in the software development and other types of IT projects. Waterfall method uses a sequential form of getting things done. All the tasks that are required for a project like planning, development, quality and testing, and maintenance are all listed in a sequence. In this, each task is listed with the start date and end date of each task. At times, a Gantt chart is used to list the activities. This is a very rigid plan and is never altered till the completion of the project unless it is absolutely necessary to do so. 4) PRiSM PRiSM stands for Projects integrating Sustainable Methods. This project management methodology is mainly used in real-estate and other large-scale projects. It considers environmental factors when working on various projects and the methods suggested by PRiSM can be easily used in large-scale projects. One of the important factors of this methodology is that it gives due credit to the project managers who are actively working on the project. The principles that are followed by PRiSM helps organizations to achieve their goals by sustainable management principles and also have the least amount of negative impact on the environment. 5) Critical Chain Methodology In most of the conventional methods of project management, the time estimated is very large as compared to the actual time required to complete the project. This is called ‘safety time’ and can extend the delivery date further. In critical chain methodology, the estimated time required to complete the task is cut in half. The core components of a project are known as the critical chain and this methodology ensures that the maximum resources are allocated to this critical chain while other processes get sufficient resources as well. This methodology also uses 3 buffers to allocate time and resources efficiently. These are: • Project buffer: It is fixed between the last task and the project completion date. If the tasks in the critical chain are delayed due to any reason, they can utilize this buffer in order to complete the task on time. The time stored in this buffer is the half of the time cut from each of the tasks in the beginning. • Feeding buffer: These buffers are fixed between the last non-critical task and the first critical task. This is done so that the delays in the non-critical tasks does not have an effect on the critical tasks. The time in the buffer is calculated similarly to project buffer. • Resource buffer: In order to ensure that the tasks in the critical chain have ample resources to complete the task, resource buffers are fixed alongside critical chain tasks. The type of project management methodology used by an organization depends on the nature of the organization. It is not necessary that the project management technique that works well for a particular organization should be successful for another organization as well
Rated 4.0/5 based on 20 customer reviews

5 Best Techniques for Project Management

550
5 Best Techniques for Project Management

Project management techniques are required to list the steps involved in a project and how to accomplish each step in order to achieve the final goal. In this article, we’re going to discuss five project management methodologies that are available in the market at present and used by various organizations.

1) Agile Methodology

Agile is one of the most widely used project management methodologies in the market right now. One of the main reasons why it is popular is its ‘sprint principle’. In this, changes can be made to the plan at any stage. The client or the development team can suggest the changes if any, and it can be implemented in the main plan. This provides flexibility to the developers, especially when working on large-scale projects. Another important feature of Agile is that it contains teams that consist of few members. This helps team members to plan and work well. The meetings that are held in organizations that follow Agile methodology are also short. It lasts for less than 10 minutes wherein the team only discusses three concepts – how much work was done? What’s the next step? What are the possible hurdles in the next step?

2) PRINCE2

PRINCE stands for PRojects IN Controlled Environments. It was initially used for government projects and later adopted by the private sector. The principles of PRINCE2 are standard such that it can be implemented in any organization around the world. The position and the description of each position are clearly defined in order to avoid confusions in the process. The core plan is divided into smaller plans in order to get the work done faster.

3) Waterfall Methodology

This is one of the oldest project management techniques that is used in the software development and other types of IT projects. Waterfall method uses a sequential form of getting things done. All the tasks that are required for a project like planning, development, quality and testing, and maintenance are all listed in a sequence. In this, each task is listed with the start date and end date of each task. At times, a Gantt chart is used to list the activities. This is a very rigid plan and is never altered till the completion of the project unless it is absolutely necessary to do so.

4) PRiSM

PRiSM stands for Projects integrating Sustainable Methods. This project management methodology is mainly used in real-estate and other large-scale projects. It considers environmental factors when working on various projects and the methods suggested by PRiSM can be easily used in large-scale projects. One of the important factors of this methodology is that it gives due credit to the project managers who are actively working on the project. The principles that are followed by PRiSM helps organizations to achieve their goals by sustainable management principles and also have the least amount of negative impact on the environment.

5) Critical Chain Methodology

In most of the conventional methods of project management, the time estimated is very large as compared to the actual time required to complete the project. This is called ‘safety time’ and can extend the delivery date further. In critical chain methodology, the estimated time required to complete the task is cut in half. The core components of a project are known as the critical chain and this methodology ensures that the maximum resources are allocated to this critical chain while other processes get sufficient resources as well. This methodology also uses 3 buffers to allocate time and resources efficiently. These are:

• Project buffer: It is fixed between the last task and the project completion date. If the tasks in the critical chain are delayed due to any reason, they can utilize this buffer in order to complete the task on time. The time stored in this buffer is the half of the time cut from each of the tasks in the beginning.

• Feeding buffer: These buffers are fixed between the last non-critical task and the first critical task. This is done so that the delays in the non-critical tasks does not have an effect on the critical tasks. The time in the buffer is calculated similarly to project buffer.

• Resource buffer: In order to ensure that the tasks in the critical chain have ample resources to complete the task, resource buffers are fixed alongside critical chain tasks.

The type of project management methodology used by an organization depends on the nature of the organization. It is not necessary that the project management technique that works well for a particular organization should be successful for another organization as well

KnowledgeHut

KnowledgeHut Editor

Author

KnowledgeHut is a fast growing Management Consulting and Training firm that is a source of Intelligent Information support for businesses and professionals across the globe.


Website : http://www.knowledgehut.com/

Leave a Reply

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

Comments

Brigida Sheasby

Hey there, You have performed an excellent job. I’ll certainly digg it and for my part recommend to my friends. I am sure they'll be benefited from this site.

Sharon Thomson

Great list of tricks one can use to manage the projects. I think you should check out ProofHub for managing your team and projects. Helps to plan, collaborate, organize and deliver projects on time.

Zariel

Good details offered here. Be sure you men submit your own imertvempnos upon Facebook too. It’s always an effective way of having more exposure. Especially if you possess plenty of followers presently there. Best of luck

Suggested Blogs

Should I put PMP after my name?

Once one obtains their PMP, also known as Project Management Professional status, the question is how do I let others know I now have this status? The 4 main places are: 1. Your business card. Once you obtain your PMP status order up some new business cards 2. The signature line in your email address. I would also recommend including an embedded hyperlink to your LinkedIn page. 3. The signature line or username on various websites you visit (message boards, LinkedIn, Face book, Twitter) 4. In your resume after your name, and within the education section. PMP certification status not only means you passed a test, it means you have been managing (or working as a team member) projects for several years and that you are willing to continue with continuing education to keep that status. This is also part of branding yourself.
Rated 4.0/5 based on 20 customer reviews
Should I put PMP after my name?

Once one obtains their PMP, also known as Project... 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, a...

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

Fail Fast: A Case Study of Agile Correcting on-the-go for Project Success

Everything about Agile Methodology revolves around key values of rapid development, adaptability, and continuous improvement.  But how many times can we, as project managers, point to specific instances where our project was saved from going completely off the rails due to Agile principles?  Most of the time, small changes, and incremental values are introduced in Sprint retrospectives, to make very small course corrections, or just to reaffirm if the development manifestation is on-point with the product vision.  And as teams mature and roadmaps develop, it becomes almost mandatory to live up to stakeholders’ expectations, since individual work relationships have been established.   Every once in awhile, especially early in new projects, Agile flexes its muscles by demonstrating that adhering to the key principles can conquer ambiguous goals and handle major course corrections — preventing a major loss of time and/or wasted resources.  Sharing these experiences is important because it demonstrates the importance of Agile processes — especially daily stand-ups, the concept of delivering a viable product unit per Sprint, and Sprint demos when we are tempted to skip or skim through them. This is one such case from my personal experience as a Product Owner on a BI platform development team. Context Business Intelligence (BI) platforms are like most software products where they require the same mix of cross-functional individuals and skills to create a viable product.  In this case, the team was comprised of three software engineers, one engineering lead, one technical project/Scrum manager, and myself as the Product Owner representing multiple end-user stakeholders.  In addition, one team member filled the role as a data analyst with expertise in ETL and data warehousing, a role unique for data and BI platform development, to help translate business requirements to functional specification for the engineering team.  A user's guide to failing faster https://t.co/TH9Y4vA9EJ #agile #IT #failfast via @opensourceway by @ghaff pic.twitter.com/0Dk3N4JzXi— Agile Alliance (@AgileAlliance) May 8, 2017 Our goal was to create an analytical cube to track and analyze the performance of a transactional engine used to register and house customer account information for the procurement and payment of software products. The transactional engine was also new, being built and iterated as we started our project.   This is, of course, where the ambiguity began.  How and where would we collect the data from this system, before data existed?  What would be the defining unit of transaction?  How will the data best represent the performance?  There was no shortage of questions, but there were tight deadlines.  Analytics needed to be live no more than two weeks after the full transactional system went live, so any failures or pain points could be quickly determined and corrected before they took root as poor satisfaction for our customers. We started working on planning a roadmap and two-week sprints, with monthly production deployments and incorporating all the normal Agile/Scrum milestones in each sprint. We took what information was available to us to determine the best course of action.  Test data from the transactional engine indicated individual units to the customer agreements, not customer accounts, and supplemental information started to form a picture of appropriate data relationships, laying out the framework of our relational databases to build.   Two sprints in, we prepared for our first production deployment on schedule.  Further out, our plan put us at completion to coincide with the transactional engine go-live date.  We entered our UAT environment testing confident and satisfied.  That is, until we started to test use-case scenarios on our UAT prototype.   Action In the UAT demo, along with the Scum manager and data analyst, we quickly realized it was nearly impossible to determine the volume of customers signing up in a time period - a pretty basic measure needed to track and provide analytical value on our program performance.  The reason why?  Customers could register and be approved to transact under multiple agreement types.  Our data model didn’t define customers uniquely, but instead, used the agreement values.  The product was designed to requirements, but the requirements did not account for the translation of data to units that were valuable to business evaluation.  When we analyzed the test data, we failed to recognize this and captured the requirements correctly.   We had to redesign our data model, and do it quickly as the deadline was fast approaching.  As we were in UAT testing, sign-off was needed to release a viable product to production.  As our first action, we agreed to proceed with the ill-designed data model for the first release, though not ideal, because the first release would meet needs for now and would not be retained for the end result.  During the next daily stand-up, we suspended our normal activities to explain to the entire team what had happened.  Agile training kicked in here, with everyone showing up, ready to take on the new challenge instead of inspecting what went wrong.   Our third sprint needed to be planned, and we decided to dedicate half the team to designing the new model while the other half designed the next phase of the project.  This could work because the next phase required acquiring additional data for our model, and integration into the data model would not start until the new design was ready.  Then came our next planning meeting, which looked much more like a Joint Application Development (JAD) session.  We were all creating the new design together instead of heavier dictation by the PO and Scrum manager.   With valuable input from the engineers, we were able to leverage parts of the old data model to translate into the new one.  This made it easier to right-size the work for our remaining sprints, and we could use our retrospective to discuss the tradeoffs that would entail.  Each stand-up of that sprint was interactive and engaging, with information and decisions being made every day.  The members of our team working on the next data acquisition were benefitting as well, understanding the new model, so that when the next integration phase came, it would be seamless.   By the third sprint demonstration session, we had a completed design and framework of a basic data model that was much more user-friendly in our test environment.  It would work with new data acquisition, and was robust enough to handle changes to the way the transactional engine worked as well. This was a plus knowing that the system could change in its infancy.  Result We were able to develop and deploy the completed BI product 10 days after the transactional engine went live, well within the two-week window we were given at start.  A good thing too, because the business intelligence revealed multiple pain-points with the transactional engine that was corrected in the first three months of activity before they became widespread issues (because it was developed under an Agile SDLC too!). Because everyone on this Scrum team had previous work experience and training in Agile, when our major defect was found, I noticed three things:   Everyone demonstrated positive and value-adding insights because we were using Agile tools both before and after the issue discovery.  There was no finger-pointing at who caused the problem, no wasting time on reiterating goals or expectation, or on additional root causing and over analysis of the issue.  Everyone leveraged their role and their cross-functional knowledge to acknowledge, overcome, and advance on the right path forward. We determined and fixed the problem very early in development, instead of waiting until a comprehensive testing window near the end of our product for it to be revealed, which would have been an even bigger issue and more rework with all the additional data and features built upon and with dependencies on the core data model. There was very little impact to meeting the project deadline. Even more so, the additional value and learning of our product due to “fast failure” influenced productive, rapid adaptation to build the “right thing”.  
Rated 4.0/5 based on 20 customer reviews
Fail Fast: A Case Study of Agile Correcting on-th...

Everything about Agile Methodology revolves around... Read More

other Blogs