Wednesday, October 26, 2016

Applied project management #14 Developing the project management plan

Through the project charter, the project manager for the project is identified. Now, the designated project manager leads the project into the planning phase, which comprises of developing the integrated project plan. Project teams comprises of multiple sub teams like;

Engineering team
Planning team
Procurement teams
Quality assurance team
Risk management team
Human resource management team
Communication team
Documentation team etc

Unless and until these sub-teams complete their individual plans, the project manager cannot complete the integrated project plan.

The project management plan is the document that describes how the project will be executed, monitored, and controlled. It integrates and consolidates all of the subsidiary plans and baselines from the planning processes.

The project baselines
Scope baseline
Schedule baseline
Cost baseline

The subsidiary plans include;
Scope management plan
Requirements management plan
Schedule management plan
Cost management plan
Quality management plan
Process improvement plan
Human resource management plan
Communications management plan
Risk management plan
Procurement management plan
Stakeholder management plan

The project management plan may include;
Life cycle selected for the project
Details of the tailoring decisions
Description of how work will be exceuted to accomplish the project objectives
Change management plan
Configuration management plan
Key management reviews for content
Requirements and techniques for communication among stakeholders

Tuesday, October 25, 2016

Applied project management #13. Project chartering

Companies have very limited resources, and they must deploy them on the best projects which will yield maximum benefits. Project chartering is the process of officially approving the start of a project by the senior management / sponsor. The project charter is prepared during the initiation phase of the project, and the accountability for preparing the charter is with the project sponsor (senior management representative). Once approved, all changes to the charter must be re-approved by the sponsor.

While developing the project charter one can refer to;
  • Statement of work (SOW)
    • Business need 
    • Product scope description
    • Strategic plan 
  • Business case of the project 
    • Market demand 
    • Organizational need 
    • Customer request 
    • Technological advance 
    • Legal requirements 
    • Ecological impacts 
    • Social need 
  • Agreements 
    • Contracts 
    • Memorandum of understanding (MOU)
    • Service level agreements (SLAs)
    • Letters of intent (LOI)
    • Verbal agreements 
    • Email or other written agreements 
  • Enterprise environmental factors 
    • Government standards 
    • Industry standards 
    • Regulations 
    • Organizational structure
    • Organizational culture 
    • Market conditions 
  • Organizational process assets 
    • Organizational standard processes 
    • Policies 
    • Process definitions 
    • Templates 
    • Historical information 
    • Lessons learned knowledge base 
    • Project management information system 
The output of the project chartering process is the project charter, a light weight document (3-5 pages) and contains but are not limited to;
  • The high level scope of the project
  • The business case of the project
  • Alternatives analysis
  • Assumptions
  • Constraints
  • High level risks
  • Major milestones with dates
  • Key stakeholder details
  • Project manager's name, roles and responsibilities
  • Project approval requirements 
An approved charter  is the green signal for the project to proceed, and is a great reference document for the project manager, team to understand the project quickly. Since charter is the only document where the project manager's name, roles and responsibilities are defined and approved by the senior management, we say that the project charter gives authority to the project manager. Many projects have multiple managers / stakeholders, and a well defined charter brings in lot of role clarity, and avoids organizational politics.

The 'project chartering' process and the output of the 'project chartering', the  'project charter'   ensures the right foundation for the projects and gives better continuity to the projects.

Think of situations where the project manager changes during the course of the project, or change in sponsor. Having a pre-defined and approved project charter gives the project with a strong foundation and provides it with better continuity, despite changes in the environment.

PMBOK Version5 reference page numbers 66,67,68,69,70,71,72

Monday, October 24, 2016

Success motivates

Hi Sirs,

After a long gap between the coaching and exam, i had scheduled my PMP exam for today.

Happy to convey that I cleared the exam. 

Thanks for your training and support

Mock exam really helped to identify the gaps and focus areas.


Best Regards,

Friday, October 21, 2016

Applied project management #12 About PMBOK

The project management body of knowledge (PMBOK) by the Project management institute (PMI) is a bulky document capturing the project management good practices captured from the project management practitioners world wide. It is a wealth of project management information which can fast track the learning about professional project management. The word 'professional' carries lot of weight here. If one gets into the shoes of a professional project manager and try to understand it, it will make lot of sense and value add. The easiest way to make your mastering of PMBOK is to get excited about every new concept of project management and the value it adds to the product or service, which is the output of the project.

The anatomy of PMBOK

PMBOK is a collection of 47 project management good practices, organised into 10 knowledge areas and 5 process groups (As of PMBOK Version 5.0). This may change as the new versions arrive, but the core will remain the same.

The 10 knowledge areas
  1. Integration management
  2. Time management 
  3. Scope management 
  4. Cost management 
  5. Quality management 
  6. Communications management 
  7. Risk management 
  8. Procurement management 
  9. Human resource management 
  10. Stakeholder management 
The 5 process groups
  1. Initiation
  2. Planning
  3. Execution
  4. Monitoring and controlling 
  5. Closing 
Every process in the PMBOK is linked to one knowledge area and one process group. For example, the process 'develop project charter' is part of the 'initiation' process group and 'integration management' knowledge area. 

Personally I found it very useful and easy to understand PMBOK by the process group wise (Initiation, planning, execution, monitoring and controlling, closing) than the knowledge area wise which is the depiction in PMBOK. When we follow the knowledge area wise grouping, it gives us the natural flow of a project, and is easy to logically reason out than mugging up.

Thursday, October 20, 2016

What do I do after my certification?

This is one question many asked me, immediately after their certification course. My honest answer is to go and do something positive with the knowledge and skills you gained. The expected answers are after PMP, do PMI-ACP, CSM, CSP, CSPO, PgMP, blah...blah...blah... When my answer is different from the answer they expected, they get disappointed. Yes, brothers and sisters..In order to survive and prosper,  I need people who chase multiple certifications on the same topic, by paying good money (either from your pockets or from your employer' does not matter who pays) , and come for every other certification on the same topic, and still not confident because you have not practiced any one of them. Please do something with what you know already, before chasing more. While interviewing candidates for a job, I never select those who have a very big tail of certifications, instead I seek those who have done commendable projects. The guy with too many certifications is not very sure about himself. Please do get certified in your chosen area, and excel as a professional, than seeking multiple certifications on the same topic. 

The habit of proactiveness

A very peaceful morning at the customers place. I reached the venue a couple of hours in advance. Had a very peceful breakfast and now into blogging at the most creative time of the day, that is 8.52 am. I have a solid one more hour to go before the start of the 'Agile project management using scrum workshop' at this beautiful workspace of this very large multinational company. I am enjoying every bit of it, despite missing my home, plants in the farm and my dog Theo, and the freshers (un-corrupted minds) of the prestigious business school where I am a visiting faculty.

What are the choices I have?

1) Do things as early as possible and relax and enjoy
2) Do things as late as possible and still complete on time.
3) Do things as late as possible , and end up late

Out of these, the third option is a sure prescription for failure and results in loss of reputation and self esteem. The second option,  which is start things as late as possible and still complete them on time is the best, from a cash flow perspective, and at the same time the risks involved are very high in this unpredictive world. The safest would be to finish things as fast as possible, and be happy about it.

Still, when it comes to personal stuff, very often I am with option 3, and for professional stuff I am almost at option 1. Those are the paradoxes within me. Be proactive is the manthra for success. I am in my constant pursuit to achieve proactiveness in whatever I do . The rewards are very high. Wish you a very good day.

Tuesday, October 18, 2016

PMP preparatory program at Kochi India on December 16,17,18 - 2016

Project Management Research Institute is conducting their proven PMP preparatory program at Kochi, India on December 16,17,18 (Friday, Saturday and Sunday)  2016. The course covers all the best practices of PMBOK, current version. Upon successful completion, participants will be awarded 35 contact hours certificate, which satisfies the 35 contact hours criteria set by PMI, USA for appearing for PMP certification. Those interested, please contact 0091 9895372115 either by phone or by whatsup.

Applied project management#11 Manage stakeholders

After identifying and classifying the stakeholders into four segments, one has to develop strategies to manage the required engagement levels with the stakeholders.

The high power-high interest group is the most critical one. They can support / kill the project. During the phase gate / stage gate meetings the project need their approval to proceed further. They must be managed very closely. The sponsors of the project falls into this category. We have to manage them very closely. Common approaches to manage the high power-high interest category are;

  • Personal briefings 
  • Workshops 
  • Risk briefings 
  • Presentations 

Then we have the high power-low interest group. The CEO of the client organization may have several things to attend to, and your project is just one of it. He/She is highly powerful and at the same time may not show too much interest in your project. We have to keep them satisfied. Some of the best approaches to manage the stakeholders in this category are;

  • Leverage existing meetings 
  • Special presentations 
  • Organizational briefings. 

The next category is the High interest - low power category. Typical end users of the product of the project falls into this category. While individually they are not very strong, collectively they become the opinion leaders, and sometimes very strong as well. Commonly used best practices to manage this segment of the stakeholders are;

  • Beta programs 
  • News letters 
  • Posters 
  • Flyers 
  • Web site 
Then comes the low power, low interest category. These are the people who do not much interest in your project and any authority to influence your project. It is safe to ignore this segment. 

As we can see, stakeholder classification, and stakeholder management strategy have a direct impact on the communication plan of your project. Both are tightly linked.

Watch this video

Monday, October 17, 2016

Applied project management#10 Identifying and prioritizing stakeholders

Very often I get this question 'What is the one key quality to be a scrum master / project manager?'. It is the ability to getting things done, very often through people who are not directly reporting to the manager. Ability to identify and influence the key stakeholders of the project, is key to getting things done on time.

The key steps of stakeholder management are;

  • Identifying the key stakeholders (Stakeholder register)
  • Classifying the stakeholders based on their power to influence the project and their interest in the project
  • Developing strategies to deal with stakeholders 

The project management body of knowledge (PMBOK), by PMI, USA have given a very good definition of stakeholders;

"Any one who is affected positively or negatively, by doing a project or by delaying / not doing a project is a stakeholder." 

I like this definition, because it prompts us to think in all possible angles, managing stakeholders. Before encountering this definition, my list of stakeholders had only two major entries like the management and the team. This definition allows me to think louder. Now the possible list of stakeholders while doing a project looks like;

  • Sponsors
  • Project managers (supplier side, customer side, consultant side)
  • Engineering managers 
  • Team members 
  • Senior management 
  • Environment 
  • Government 
  • Competition 
  • Suppliers 
  • Buyers 
  • Users 
  • Political parties 
  • Myself 
This is a quick list, which is not complete and will change from project to project. The definition given by PMI, helped me to broaden my perspective about stakeholders. To be effective manager, preparation of the stakeholder register and maintaining them throughout the project (stake holders may change during the course of the project) is the first step towards professional project management. 

After identifying the stakeholders, the next step is to classify the stakeholders based on their power to influence the project, and their interest in the project. 

If we have to understand the power equations within a business entity, we should understand their organizational structures. 

Functional organizations

This is the most prevalent traditional organizational structure. In the functional organization. the project managers have least authority levels, and the functional manager is very powerful.  

Matrix organizations

One of the key attributes of matrix organizations is dual reporting. For the project related tasks one may report to the project manager, where as for the department related work the reporting can be to the functional manager. The power of the project manager is slightly better than the functional organization.  Matrix organizations can be further classified into;

  • Strong matrix (Project manager has more power than the functional manager)
  • Balanced matrix (Project manager and the functional manager share the same level of power)
  • Weak matrix (Project manager has lesser power than the functional manager)
Projectized organizations 

In projectized organizations, the direct revenue earning activity are managed as projects (Construction companies, I.T companies). In projectized organizations, the project manager has the maximum authority and is more powerful than the functional manager. 

Without understanding the type of the organizational structures of the stakeholders in the stakeholder register it is impossible to understand the decision makers and the decision influencers, which has a major impact on developing strategies to deal with stakeholders. This has a direct impact on communication plan as well. 

Here is the video explaining stakeholder management 

Wednesday, October 12, 2016

Applied project management#9 A burndown chart for everything

A burn down chart is a simple yet very effective tool to track and proactively manage the progress of a project towards a milestone. It is analogous to landing a flight within the runway. When we approach the destination, the pilot announces the current altitude of the plane, the distance to the runway and the tentative time required to reach the destination. In this case, what goes on to the 'Y' axis is the altitude, and 'X' axis represents the distance to the destination. For projects, the 'Y' axis has the cumulative estimated effort to complete the balance tasks, and the the 'X' axis represents the duration of the sprint / milestone / release / project. When we use a burn down chart to track the progress of the sprint then we call it as a sprint burn down chart. If it is used to track the progress towards a major release of the product, then it is called 'Release burn down chart'. I use it to track the progress of my training programs, and I call it as the 'Training burn down chart'.

Here are two videos. The first video discusses the purpose of burn down charts. The second video discusses about updating the burn down chart daily.



Tuesday, October 11, 2016

Sorry for samsung

A sunk cost of USD 17 billion with the recall of Samsung note7. Luckily I did not buy one, so no direct impact on me. Definitely this is a classic example of price of non conformance. Cost of quality  (COQ) = price of conformance (POC) + price of non conformance (PONC). All those actions we take to prevent problems from happening falls under price of conformance. Everything we do to fix problems post occurance , falls under price of non conformance. In this case the price of non conformance alone is a whopping USD 17 billion. Next time we discuss this , please do not label it as theory. This can happen to anyone. I am sure that many heads will be rolling within Samsung. If the project fails, the project manager is accountable for it. It makes perfect business sense to invest in POC than PONC.

Reference link

Reference books

Quality without  tears,  quality is free both by Philip Crosby

Sorry for samsung

A sunk cost of USD 17 billion with the recall of Samsung note7. Luckily I did not buy one, so no direct impact on me. Definitely this is a classic example of price of non conformance. Cost of quality  (COQ) = price of conformance (POC) + price of non conformance (PONC). All those actions we take to prevent problems from happening falls under price of conformance. Everything we do to fix problems post occurance , falls under price of non conformance. In this case the price of non conformance alone is a whopping USD 17 billion. Next time we discuss this , please do not label it as theory. This can happen to anyone. I am sure that many heads will be rolling within Samsung. If the project fails, the project manager is accountable for it. It makes perfect business sense to invest in POC than PONC.

Reference link

Reference books

Quality without  tears,  quality is free both by Philip Crosby

Applied project management#8 Story sizing

While doing the story sizing, I have found the 8/80 rule from the traditional project management very handy. the 8/80 rule, is a rule of thumb for sizing the work packages. It states that work packages must be something that can be completed between 8 hours (1 day) and 80 hours (10 days). Larger the product of the project, the affinity of the work packages should be towards 80 hours chunks of work. If the product of the project is small, then the affinity of the work packages should be towards 8 hours chunks of work. A very large project with work packages of around 8 hours effort will lead to micro management. Similarly a small project with workpackages towards 80 hours will lead to lack of visibility and last minute failures, without much recovery time.

For 30 days sprint, which has all the characteristics of a small project, it is worthwhile to maintain the story sizes between 8 to 32 hours. If you have very large stories which does not fit into this range, break them further. Again, do not consider it as a rule, it is just a guideline. Final decision is yours.

For any queries, please use the askaby link.

Monday, October 10, 2016

Applied project management#7 What happens after the sprint planning meeting?

One the sprint planning meeting is over, the next is sprinting. During sprinting, the team members volunteer for tasks (not features) and completes them. When all the tasks associated with a feature / story is completed, then it is moved to done status. Here the definition of done plays a crucial role. A good definition of done for a software project related task could be;

Coding done
Code reviews done
Unit testing completed
Integrated testing done

If the definition of done is stronger, the right spirit of 'done' which is 'nobody will work on it again' is achieved. Ironically i have seen very shallow definitions of done like ;ready for testing' . That is a problem, as well as an opportunity to improve further.

Teams which are conditioned for work allocation may find it difficult to switch over to work voiunteering overnight. Personally I am not really motivated when others allocate work to me. I am at my best, when I choose to do something. Even if a transition from work allocation to volunteering is slightly painful, it is a great opportunity for the engineer. I see it as a liberation of the engineer from the clutches of obsolete command and control styles. If you do not grab it with both hands, others will be telling you what you should be doing, till you retire. So grab this opportunity.

Here the capability to contribute to the product of the project matters. A traditional manager with only monitoring capability will fail miserably in these teams unless he / she is willing to unlearn and learn. Sometimes, false ego plays a destructive role here. To be frank, this is when I picked up story writing skills, and testing skills. I am grateful to agile for that constructive compulsion.

It is advisable for a person not to choose more than two to three tasks at a time. When you volunteer for a task, you write your name on the task (sticky note representing the task) and move it to being done status. When you complete the task you move it to done status. When all the team memebers does this religiously, work become very transparent.

Can a scrum master volunteer for regular tasks?. This is a question I receive very frequently. Technically there is no problem for this. Before volunteering for a task, think twice to ensure that you have the time and resources to complete it, else you will become a bottle neck.

While sprinting, you have daily standup meeting (scrum), where each team member gets 2 seconds to explain three things to the rest of the team;

What did I do yesterday?
What am I doing today?
What are the challenges I am facing and need help?

The sprint burndown chart is also updated daily. Will talk about these in detail later.

Good day

Saturday, October 8, 2016

Applied project management#6 What happens during the sprint planning meeting?

As discussed earlier, everything is time boxed in agile. So, is the sprint. A sprint is a cycle of maximum 30 days, during which an increment of the product is really built. I have worked with weekly, fortnightly and monthly sprints. The duration of the sprint is determined by several factors such as;

  • Theme of the sprint
  • Current version of the product 
  • Size of the features 
  • Amount of functional risk involved 
  • Amount of technical risk involved 
  • Degree of teaming 
  • Trust level between the product owner and the development team 
If the product is in the earlier phases of development I recommend shorter sprints, and once the technical, functional and teaming related risks are addressed, the teams can switch to longer sprints, still not exceeding thirty days.

Every sprint starts with a sprint planning meeting, which is time boxed to 8 hours for a thirty day sprint. If the sprint duration is lesser, there could be a small decrease in the sprint planning meeting time. However it is very difficult to conduct any meaningful sprint planning meeting within 5 hours time. The sprint planning meeting is attended by the product owner, scrum master, development team and other special invitees. 

During the sprint planning meeting, the following happens; 

  • The product owner explains the prioritized list of features to be developed during the sprint 
  • Product owner clarifies all the queries regarding the functionality
  • The team estimates the story points for the stories associated with the prioritized features
  • Matches the story points to the story points achieved during the previous sprint (velocity)
  • Once there is a lock in (agreement) on the features that can be developed during the sprint, the team breaks the stories to tasks and estimates the effort required. Unlike traditional models, there is no need to strive for lot of accuracy for the task level estimates, as the engineers are allowed to revise task level estimates every day of the sprint, based on their hands on experience with the task. 
  • Before the completion of the sprint planning meeting, based on the task level estimates, it will be useful if the team can compare across the stories. The cumulative effort of the stories with higher story points must be more than the ones with lower story points. It will be useful, if we just look for patterns. 
  • The output of the sprint planning meeting are the agreed upon features, associated stories, their story points, associated tasks and the task level estimates. 
This data is used to plot the tracking board and the sprint burn down chart. 

Friday, October 7, 2016

Applied project management #5 story point estimation

Have you ever come across any project which got completed within the agreed upon time within initially agreed upon budget?. I am yet to. Still we strive for accurate estimates which is conflict with the basic characteristic of progressive elaboration, which is applicable to all projects. In the agile world, we do not strive for too much accuracy for estimates and at the same time we need some kind of a budgetary estimate. We have to define the roadmap for projects and plan for the necessary resources for the project even if they are not definitive (rolling wave or moving window planning). In order to make a definite quantity of fruit salad we need to know how many Apple's, oranges and pineapples are required. We are not really worried about whether it is a large, small or medium sized apple.

In a similar fashion, the stories are given weightages based on the amount of work involved to complete them. The most commonly used scale is the fibonacci series of 0,1,2,3,5,8,13,21 and so on where 1 is the least. 0 is for those stories which are not possible to estimate at the moment.

Playing poker is the most popular estimation technique used. The ser stories to be estimated are explained by the product owner and all the queries by the estimation team are answered. Then the estimators individually assign a weightage to the story under consideration. During this process discussion among the estimators are discouraged to avoid any sort of bias. Once the story points are allocated individually then they are shown together and consensus is achieved through discussions. Decisions based on majority   or seniority are not allowed. Everything is driven my meritocracy of the logic, idea.

If we take a closer look at poker for estimation, it is the implementation of the good old technique of wide band Delphi, where experts estimate individually and then consensus arrived.

Tuesday, October 4, 2016

Applied project management #3 Quick overview of scrum

  • Scrum is one of the most popular frameworks under the agile umbrella. 
  • Simple to understand, and difficult to practice as it is value driven, than rule based. 
  • Highly transparent, based on empiricism.
  • Revolves around Plan, Do, Study and Act (PDSA) cycle by Deming.
  • Highly committed, capable teams is a must to have successful scrum implementations, as the work revolves around self organizing teams. 

  •  They key roles in Scrum
    • Product owner (who maintains the product backlog, an prioritizes the features for development) 
    • Scrum master, who is accountable for implementing scrum and removing impediments faced by the team during development. 
    • Development team converts the agreed requirements into product increments

  • The key ceremonies of scum
    •  Sprint planning meeting 
      • An eight hour planning meeting for 30 days sprint (iteration), which is the maximum allowed duration of the sprint. For shorter sprint duration, the sprint planning meeting time can be shorter. However, it will take a minimum of approximately five hours to conduct a proper sprint planning, irrespective of the duration of the sprint. 
      • During the sprint planning meeting, the product owner proposes a prioritized set of features to the development team. The product owner clarifies all the queries of the team. The team estimates the amount of work involved, and then commits. 
      • The output of the sprint planning meeting are the sprint review date, time and  the sprint backlog, which comprises of the agreed upon set of features, the tasks required to build those features, their estimates and the acceptance criteria.
    • Sprinting
      • The team starts converting the items in the sprint backlog to the increments of the product. There is no work allocation. The team members volunteers (self organize). 
    • Scrum (Daily standup meeting)
      • Every day, the team conducts a stand up meeting, where each member communicates three things to the rest of the team in two minutes time;
        • What did I do yesterday?
        • What am I doing today?
        • What are the issues I am facing and need help to resolve them? 
    • Sprint review meeting 
      • Upon the agreed upon date and time (sprint planning meeting), the increment of the product built during the sprint is demonstrated to the stakeholders. If all the agreed upon acceptance criteria (sprint planning meeting) are met, the sprint is considered as successful.  
    • Sprint retrospective meeting 
      • The sprint retrospective is conducted to analyze  the lessons learned during the sprint, both positive and negative, with a view to improve the subsequent sprints.
Download the official scrum guide 


Monday, October 3, 2016

In the company of young MBA students

My first experience in teaching in a management school. So far so good. Young crowd, bubbling with energy and hungry for knowledge. Not yet bound by the corporate rule books and the unwritten rules of the bosses :-)

Saturday, October 1, 2016

Applied project management #2 Project strategy

Let us take a look at the definition of projects;

  • Projects have definite start and end dates.
  • Projects are performed by people. 
  • Projects are temporary in nature. Upon completion of the project, the project team is dismantled. 
  • Projects deliver unique products or services as output 
  • Projects are progressively elaborated. When we start a project, we have very less information about the project. As we progress, we gain more insight about the project. This we call as progressive elaboration. 
As we can see, projects deliver unique products or services as output, hence no two projects are same. There cannot be a fit for all type of project strategy. Based on the nature of the project at hand, one need to spend time in developing a project strategy, which is the best for the project. Broadly we can classify the projects on two parameters; requirements and technology. For some projects requirements can be very clear, and for some requirements could be very ambiguous, or it could be anything in between. For some projects the technology can be very familiar to the team, and for some, the technology could be very new to the team.

For projects where requirements are ambiguous and technology is very new to the team, then developing an end to end plan could be a futile exercise, because things will change rapidly. These type of projects are the right fit for Plan, Do, Study and Act (PDSA) cycles. The project is iterated (fast PDSA cycles, with a maximum iteration duration of 30 days), with a view to fail fast, and to learn from failures and successes, to incorporate them into the subsequent iteration. This is the right approach for new product development, research & development kind of projects. The project management frameworks revolving around PDSA based rigorous iterations falls into the umbrella 'Agile'. There are multiple flours of it and the most popular ones are Scrum, XP, RUP, TDD, Devops etc. Fast failures are celebrated in these models.

For engineering disciplines like construction, mechanical, electrical, plumbing etc, the engineering discipline itself does not allow for change. Once the foundation is laid, we cannot have major scope changes to any construction project. These kind of projects call for end to end planning, and revolves around Plan, Do, Check, Act (PDCA) cycles.   The projects are planned from start to end, and everything is managed as per the plan. Very often, every deviation from the plan is treated as failure. The traditional project management frameworks like PMBOK and PRINCE revolves around PDCA. Of late they are trying to include the PDSA approach as well.

The time invested to identify the nature of the project at hand and then choosing the PDSA or PDSA or a combination of both, is a good investment. If we apply PDCA to a project where requirements are not clear and technology is unfamiliar to the team, then it will be doomed sooner or later. If we apply PDSA to a project where requirements are very clear and technology is also very familiar to the team, then it will be an over kill.