Agile in EPC projects – Why I am super delighted?

Can we use agile principles outside I.T?. This is one question I had to answer many times during my project management workshops, and consistently my answer was/ is ‘Yes’. I have mentored a team of lawyers who analyse outsourced cases and submit case analysis reports back, to follow ‘scrum’, one of the agile methods.

Another question from an architect of Turner construction was about the applicability of agile / lean principles in EPC projects. This was around seven years back. My answer was ‘Partially possible’. Agile gives best results in projects where the requirements are evolving and the technology is also new to the team. The early phases of EPC projects (contracting, requirements collection, scope definition, architecture, engineering phases) satisfies ‘evolving requirements’, ‘technology ambiguity’ criteria very well, which justifies my answer ‘partially yes’. The rolling wave or moving window planning which is part of PMBOK for the last one decade, in it’s fully expanded form is nothing but iterative and adaptive in nature. I was always optimistic about application of agile and lean practices in EPC projects, except during construction phase.

Last week, I received a McKinsey report on the emerging trends in EPC from Mr. Varghese Daniel, CEO, Wrench solutions with whom I am professionally associated to analyze the global project management best practices and their application to EPC projects to improve on time and within budget delivery. My further googling got me another KPMG study on the emerging trends. Both points to Integrated Project Delivery (IPD) as one of the key trends globally, which revolves around better collaboration of motivated teams achieved through;

  • Choosing the right contract types (tri-party contracts between the owner, contractor and the architect)
  • Greater collaboration during planning phase (last planner – which is similar to iteration planning)
  • Greater collaboration during execution (construction) (burn down charts, information radiators, daily stand up meetings)

At last my hunches are coming true. All these years I was the lone crusader who used to say that adaptive(agile) and predictive (PMBOK, TCM, PRINCE2) are complimentary which raised many eyebrows, and as an acknowledgement of my views, the industry is moving towards it. I am super delighted.

About the blogger

Abrachan Pudussery is a highly experienced project management domain expert with three decades of project experience in project management, consulting, coaching and research. He has in depth knowledge about various project management frameworks (PMBOK, PRINCE2, TCM, Agile. He is the founder director of the Project Management Research Institute He is also associated with Wrench Solutions as their project management domain expert.

Agile nirvana – An iterative and incremental list

Everybody wants true peace (nirvana) and very few achieves it. In I.T, majority wants to go for agile, and they take a plunge, but very few reaps the real benefits of agile. They are quite satisfied with the benefits the ceremonies like daily stand ups, planning meeting etc, without really dwelling into the benefits of culturally challenging stuff like work volunteering, true retrospectives, velocity calculations, agile principles etc..If one can get up early, walk up to the place of worship, being part of the prayer group also provides a sense of well being, and many get satisfied with the tip of this iceberg of benefits. Following agile very often resembles being part of an elite group physically, without any mind share. Very often the ‘association’ tag alone helps to elevate the social status of the individual, even when they are not part of it in the true sense. Here are some of the reasons why people follow or want to follow agile …

1) Some plunge into it, because they are so fed up with the current state. They want to improve the way they do work, and the resulting product.

2) Some follow it, because the customer is insisting for it (contractual obligation).

3) Some follow it because anything is fine with them.

4) Some follow it because they want to learn it, and get ready for the next job.

5) Some others follow it, because they want to add the word Ágile’ to their resume.

6) Some follow it, to learn it.

7) Some follow it to use their learning.

8) Some follow it to prove that agile is a failure, and will not work for their team / organization.

9) Some follow it to discipline their bosses (chickens).

10) Some follow it to make the product owner  more accountable for the requirements.

11) Some use it to focus their guns on the opposition (organizational politics)

12) Some follow it because they want to get trained on agile, at the company’s expense.

13) Some follow it, because they do not know any sort of project management, and they want to start with agile.

14) Some follow it because it is someone’s KRA (Key responsibility area)

15) Some follow it, because of peer pressure.

16) Some follow it to become a scrum master

17) Some follow it to prove their capability, beyond their job title

18) Some follow it to become a PMI-ACP

19) Some follow it to understand it, so that they can audit a project better (violation)

20) Some follow it, hoping that it will resolve all their organizational problems

21) Some follow it, because they want to build great products

22) Some follow it because they want to improve their work culture

23) Some follow it to build an organizational culture

24) Some follow it, to reduce cost

25) Some use it to improve productivity

26) Some use it to escape from unpaid overtime (agile talks about 8 hour working days)

27) Some use it to please the management

28) Some use it to improve themselves as a professional

29) Some use it, because they see it very close to the natural way of doing things

30) Some use it, to master it, to become consultants and trainers

31) Some use it, because they already bought an overpriced certification, and want to use it somewhere

32) Some use it, to tell their customers that they are agile

33) Some follow to get everyone in office at sharp 9, they even have evening standups to ensure people leave not before 9

34) Some follow because they have been told to follow, just one more status report (not a replacement), since the people who told them to follow like things the way it is, they have just been told to follow themselves.

35) Some follow, but are still too immature to manage people. Its more a process/job to them then the “culture” agile demands.

36) Some follow a lot, and fall on their face, because they cant say no to their bosses.

Incomplete….feel free to add….

Anyway everyone is using it…..

Multi dimensional risk analysis for PMP

Here is a multi dimensional risk analysis for the PMP credential from the industry, trainer, PMP aspirant perspectives with an intent to communicate an independent and unbiased view. 


Industry related risks 

  1. The risk – There is a wide spread rumor about PMP credential as a product, which has reached the end-of-life stage in the product life cycle.  Reality – While this can be true from the training providers perspective due to too many trainers / companies undercutting each other, this is never true from the project management professional’s / aspiring professional’s perspective. PMP still rules as most recognized certification for predictive project management (most suited for large projects involving engineering, procurement, construction and management (EPCM). PMP credential is followed by PRINCE2. There is no other choice as of now for anyone who wants to pursue a globally accepted predictive project management related certification based on Plan, Do, Check, Act (PDCA) by Deming. I am using the term ‘predictive project management’ explicitly because there are many popular certifications available under the agile family (SCRUM, XP, RUP, TDD etc..) which are not a right fit for EPCM projects where the engineering discipline does not allow for much change, hence the agile family of frameworks are more suitable for product development where the requirements and the technology are highly volatile. Even then I am toying with the idea of applying agile during the planning phase of EPCM projects. Do not pelt stones at me because I am talking differently, or because I am the only one talking so. Unfortunately the agilists and the traditionalists do not like each other very much, even when the scrum masters fail miserably because they do not have any clue about stakeholder management, risk management, communication management, resource management, scope management, quality management etc. In my personal opinion, predictive and adaptive (agile) project management streams are complimentary  in nature for those whose goal is to manage their projects successfully, without bias towards any one particular framework.

Trainer related risks

  1. Many trainers teach the inputs, tools and techniques and outputs of the project management processes, in the same sequence as they are listed in the project management body of knowledge (PMBOK), without focusing on the benefits. That makes it very boring and difficult to remember (note that PMBOK is a 750+ page document). A better approach would be to learn process group wise;
    • Initiation
    • Planning
    • Execution
    • Monitoring & Controlling
    • Closing – This approach makes it easy to remember, as this is the natural flow of the project.
    • processgroupwisedoclist
  2. Many trainers provide too much emphasis on remembering inputs, tools&techniques and outputs (ITTO). Remembering them for 49 processes is humanly impossible, especially when one is under exam pressure. In fact, surprisingly those who spent maximum effort to mug up ITTO during their preparation time have failed in the final exam. Once you understand PMBOK process group wise, it is easy to recollect logically the inputs, tools&techniques and outputs. For example remembering the ITTO for the process ‘Develop project charter’ is much easier when one looks at it as the first process under ‘Project initiation’ process group, than the ‘First process’ under ‘Project integration management’ knowledge area.
  3. They do not give any emphasis on the ‘professional ethics’ of project managers. You can imagine the plight of someone who tries into master professional project management without any idea about professional ethics. Since the questions are scenario based, every project management scenario has an ethics angle, and mastering it makes it easier while choosing the best project management decisions.
  4. PMBOK has a wealth of information for the project management practitioner. Many trainers lacks the experience to articulate the concepts from the practitioner’s perspective. For example, project charter can be explained as just an output of project initiation or it can be a great document to develop a well understood project success criteria among all stakeholders..
  5. Trainers may not be well versed with various project domains to cite the right examples, whereas the participants are from different domains. They end up seeing everything as a nail, because the only tool they have is a hammer.
  6. Trainers trying to showcase their knowledge than focusing on the knowledge transfer. Mostly with inexperienced trainers.
  7. Trainers who does not explain things in detail, due to monotony. Mostly with highly experienced trainers.
  8. Trainers recommending too many reference material, thus making the preparation difficult.
  9. Trainers who charge very less fees, who losses interest mid way through the course because they are not compensated enough for their efforts.
  10. Disillusioned trainers, who are wearing the trainer’s hat out of compulsion than by choice.

Learner related risks

  1. Underestimating the effort required. One need to spend atleast 80 hours of preparation time, which include training, self study and exam practise.
  2. Over confidence, hence insufficient preparation.
  3. Lack of confidence, hence not scheduling the exam and finally dropping the idea.
  4. Enrolling for cheap courses, just because they are cheap, without giving any weight age for trainer profile, method of training and track record. Online courses which are just record and play, which are priced lower than the price of books is the number one culprit. Think of the frustration, re-preparation effort and the re-registration fees after failing in the first attempt. Passing PMP in the first go is very important. Do not decide based on the direct costs alone, consider the indirect costs (especially the cost of failure) as well, before deciding on the training program.
  5. Try to finish it off at the earliest, preferably within 30 days of the course completion, else other priorities may take precedence.


7 steps to define good project requirements?

  1. Identify the project’s stakeholders
  2. Classify them into groups of;
    1. High power – high interest
    2. High power – low interest
    3. Low power – low interest
    4. Low power – high interest
  3. Collect the detailed requirements from the relevant stakeholders through;
    1. Interviews
    2. Questionnaires
    3. Brainstorming
    4. Requirements development workshops
    5. Benchmark with similar projects / products
  4. Analyze the requirements
  5. Define requirements
  6. Collect feedback (prototyping)
  7. Freeze / baseline requirements

Every project starts with a high level scope description. Sometimes it can be just a problem definition. This has to be elaborated into detailed scope. The first and foremost step is the identification of the stakeholders of the project. Stakeholders are anyone who are affected positively or negatively, directly or indirectly by doing the project, or by not doing the project, or by delaying the project. Unless and until we identify the key stakeholders, requirements definition can err.

The following diagram depicts the stakeholders for an online project management course;

Online Project Management Course Stakeholders

A good understanding of the key stakeholders is the first step towards collecting good project requirements. Once the stakeholders are identified, we are ready to collect / develop detailed requirements from the key stakeholder’s perspective. From the above stakeholder diagram, it becomes easier to visualize the high level major modules like;

  • Administrator module
  • Participants module
    • First time visitors
    • Repeat visitors
    • Progress / scores
  • Instructors module
  • Content developers module
  • Payments module

Can we estimate these modules?. The answer is ‘No’ because they are at a very high level. They need to be elaborated further. The jargon used for requirements engineering for traditional project management and for agile project management differ and at the same time the ‘common goal’ is to identify and define accurate and relevant requirements hence an awareness of these jargon will be helpful.

Requirements collection

In traditional project management we collect detailed requirements through interviews, questionnaires, brainstorming with the stakeholders. The requirements thus collected are analysed, elaborated and documented as the requirements specification document.

In the agile world, everything starts with the product backlog. The product backlog contains the wish list of features that may or may not get into the product. The very high level features which needs to be broken down further are known as epics. In our example of developing an online project management course, the following are at an ‘epic’ level, which need to be decomposed further into features (The list of probable features are provided within brackets).

  • Administrator module (Super admin, admin, authorizations, revokes )
  • Participants module
    • First time visitors (registration, enrollment, language)
    • Repeat visitors (course)
    • Progress / scores (sponsor, student)
  • Instructors module (course development, evaluations, time tables, assignments, tests)
  • Content developers module (development, submission, quality control, multi language)
  • Payments module (payments, refunds, credit cards, debit cards, bank transfer, multi currency)

What we have now are the epics and the probable features related to the epics. These features are further broken down into ‘user stories’.

Contents of ‘user stories’ 

  • Header – New User registration
  • Description :
    • As a new user I can create my unique user-id and password
    • As a new user, I should be able to choose the course of my interest
    • As a new user, I should be able to see the profile of the instructor
    • As a new user, I should be able to see the details of other participants
    • As a new user, I should be able to see the details of the course
    • As a new user, I should be able fill up my profile
  • Conversations – are captured as and when someone has a query
  • Acceptance tests
    • User id must be unique, between 7 to 15 in length. Can contain alphanumeric.
    • Must contain one digit, one capital letter

A user story must be something that can be developed and demonstrated within 2-4 days time. If that criteria is not met, then that story must be broken down further into sub-stories. The sequence goes like this;

  • High level scope
    • Epics
      • Features
        • User-story
          • Sub-story

Irrespective of the framework or the development cycle followed, our objective must be to collect accurate and relevant requirements without any ambiguity, in the shortest possible time. Product backlog / epic/ feature / story route is my preferred path, because it is easy to manage. Sometimes we get the requirements specification as an input to the development process, in that case decompose the requirements documentation into stories (when we write the acceptance tests, the clarity of the the requirements increases). If the customer wants the requirements specification document as a deliverable, then take the agile route for requirements engineering, and then combine all your stories to form the requirements specification document. Remember ‘The cost of managing requirements related defects during the requirements phase is one hundred times lower than correcting them once the product is developed’.


Application of theory U, in agile coaching

Right now I am in the middle of a consulting assignment of transitioning a large team from ‘scrum buts’ to right scrum. When I say right scrum, I refer to the scrum guide by Ken Schwaber and Jeff Sutherland which can be downloaded from

This team from a very large multi national product company came with the baggage of ‘I know scrum, and now you teach me scrum’ attitude, because they have been practicing some sort of scrum, and this was not new for me, as I have seen the same attitude in several other teams. Since agile is value based, like religion, once the faith is lost,  it is very difficult to restore it. No amount of persuasion would have convinced them. At least that is my judgment, based on experience with similar teams with some experience in scrum (scrum but teams). In the normal course, I would have proceeded with that judgment.

As a coincidence, this is the time I came across the theory ‘U’ which was advocating the postponement of the three fears of;

  • Fear of judgment
  • Fear of cynicism
  • Fear of change

for effective change management.

I decided to implement the concept of ‘postponement of these fears’ at every stakeholder level, me being the first one. All the coaching sessions started with the request to postpone these fears till the completion of the first sprint, and the results are very positive. After experiencing the right scrum, most of these fears are automatically addressed and eliminated.

15 points for effective daily stand up meetings (scrum)

  1. Start the meeting on time and finish it on time. Some teams do it at the beginning of the day. Some do it by 11 a.m. Some do it towards the end of the day. This can be a challenge when you have teams working from two different geographies with time zone differences. Choose the time slot that works for you, and stick to it, till it works, and when it does not work for some reason change the time of the meeting.
  2. Like every other ceremony of scrum, the daily stand up meeting is also time boxed into a maximum of 20 minutes. That means, for a ten member team, each person gets approximately 2 minutes to update the status of his/her work to the rest of the team (what did I do yesterday, what am I doing today and what are the issues I am facing. If the stand up meeting is exceeding the time box of 20 minutes, then correct it.
  3. Do not convert the daily stand up meeting into issue resolution meeting. Sometimes, logistically it is convenient to have the issue resolution meeting immediately after the daily scrum. In that case, conclude the daily scrum (daily stand up meeting) formally, before starting the issue resolution meeting, so that only those required need to participate in the second meeting and all others can go back to work.
  4. As in every other meeting, during the daily scrum also, the team members tend to talk to the senior most person in the group. In that case deliberately cut the eye contact with that person so that he/she will be forced to have eye contact with the rest of the team. This is the team’s meeting, just to see the status of the project together. By talking to the manager / scrum master, you are again falling back to the command and control mode, rather than the desired self organized teams.
  5. Please remember that going for a meeting late or skipping an agreed upon meeting are not positive indicators of mutual respect. Exceptions are fine, but if not controlled they can become the rule.If somebody violates the meeting norms anyone in the team can highlight it so that the correction happens then and there itself, before it becomes a team norm.
  6. Every one must stand up during the stand up meeting. There is a purpose for having a stand up meeting, instead of a sit down meeting. The objective is to have a quick and effective meeting within twenty minutes. Those lethargic souls and bodies, please excuse.
  7. Switch off mobiles. There is nothing more irritating than the mobile rings. These break the tempo and rhythm of communication. Even worse is answering the phone calls during the meeting.
  8. Demonstrate mutual respect and team work. When a person talks (updates his work status), listen with an intent to understand, and help, if required.
  9. Stand up in a circle, so that there is no hierarchy.
  10. Do not stand with the boss on one side and others on the other side.  This creates a divide.
  11. Who will start the meeting?. The person standing on the right side or left side of the scrum master, or on the left side. Go clock wise or anti clock wise, but have a norm, that is very important.
  12. Whenever someone requests help / highlight the challenges faced, note it down with an intent to help him/her. Remember, success of the sprint is joint responsibility.
  13. Always have the scrum meeting near the tracking board.
  14. If there are any action items for the scrum master, and if the scrum master is not available in the meeting (as per the latest scrum guide, scrum master’s presence is not mandatory in every scrum meeting), assign tasks to the scrum master, immediately after the daily scrum or just after it, so that she can work on them.
  15. Conclude the meeting by putting your hands together for the progress made. Celebrate even small achievements. Small achievements leads to big success stories.

Trust this helps.


At XIME – Xavier’s institute of management and entrepreneurship

The project management certification guide – 2019

It is cut throat competition out there in the certification arena. Every certification body wants to get a pie of the project management certification market. There are the established certification bodies which faces stiff competition from the new comers.   It is a red-ocean out there. The leaders of predictive project management want a share of the adaptive (agile) project management window. The PMI and the PRINCE2 owners are trying their luck in the agile segment and are struggling in the agile space which is dominated by the likes of Scaled Agile,  Scrum alliance,

The sole objective of this post is to bring clarity to the cluttered certification options, to make it easier for the reader to  choose the right certification or guide others towards the right direction.

Project Management can be broadly classified into two main categories;

  1. Predictive project management – A plan is created for the project from start to finish, and we execute the project as per  the plan. This is well suited for projects where the scope is very clear, and the engineering discipline does not allow for much change (EPC projects).  Most of the engineering, procurement and construction projects demand predictive project management styles because their engineering domain are not suitable for frequent scope changes. The leading players in this segment are;
  2. Adaptive / Agile project management  – Adaptive or agile project management is well suited for projects where the scope is evolving and the technology is very new. These are iterative in nature. The product of the project is developed through small iterations. These are well suited for projects whose engineering domain allows for easy scope changes (I.T projects). The leading players in this segment are;

The following chart depicts the certification streams under two main categories; Predictive and Adaptive or Agile.

PM Career Guide 2019 - high


Contact us 




PMP with Agile

Here is a great opportunity to master agile project management while preparing for your PMP credential. We have been using agile project management to manage our classroom training for more than three years successfully, and now we are delivering our online training programs also using the agile tools, especially sprint planning, sprinting, sprint reviews and retrospectives.

Key benefits

  1. Your PMP preparation is managed as a project, hence have  definite start and end dates.
  2. The scope covers till your writing the PMP examination, hence better probability of success.
  3. The course is divided into iterations (sprints). The duration of the iterations are decided by the instructor and the participant based on the number of hours the participant can spend for this course per week.
  4. At the beginning of every sprint, the instructor explains the scope of work for the sprint, explains the key concepts to the participant.
  5. During the sprint, participants are required to complete assignments in the form of reading and open book learning tests.
  6. Upon completion of every sprint, the instructor and the participants review the progress made during the sprint.
  7. Performs the sprint planning for the subsequent sprint.

For a person who can commit 10 hours of study time per week ( 1 hour per working day (Monday to Friday, and 5 hours during the weekends), the course can be completed in four weeks time.

Upon completion of the course, the participants will receive two certificates from the Project Management Research Institute;

  1. ‘Introduction to agile project management using scrum’ certificate
  2. Pmdistilled PMP preparatory course certificate with 35 contact hours

For more information contact us 



Do not loose your agility

In order to have an overall understanding of scrum framework, it takes only a couple of hours of reading of scrum guide. As per the founders of scrum, it is a framework which is easy to understand but difficult to implement. The reason being, it is a value based system than a rules driven system. Several discussions are going on in the social media about ‘what is agile?’. I like those self introspection by agilists , because all of us can easily and conveniently forget the fact that agility is based on continuous improvement and it can happen only in an environment based on;

  • Commitment (to the work)
  • Focus (Focused work)
  • Openness (Work environment where people can share their views without fear)
  • Respect (Self respect and mutual respect)
  • Courage (Courage and confidence for decision making)

Many sponsors of agile initiatives do not focus on these aspects, or by the time they realize that these are important,  their organization would have already developed a culture of it’s own with it’s roots on command and control systems, because they hired people with those backgrounds. In such environments, the idea of self organizing teams take a beating. Unfortunately, it is very difficult to re-engineer culture, once it is set.

As an entrepreneur, if you really want to develop a culture conducive for agile and self organizing teams;

  1. Start early, when the organization is still small.
  2. Define your value system (what type of a work environment you want to create)
  3. Recruit the right people who can align with the value system.
  4. Allow the processes to evolve based on the team retrospectives
  5. Do not stick to any one agile framework. Scrum can be a good starting point, then start looking at all other frameworks for good practices.
  6. Implement a reward and recognition system which support the value system

Things to avoid

  • Do not recruit managers/leads who do not have conviction on agile. Many large organizations push their managers to agile certifications just to boast about the number of certified agile masters they have. Certifications does not mean that they are good in agile. Certified scrum masters with conviction on scrum is a very rare breed. If you spot one, recruit, else wait.
  • Avoid recruiting managers who are not willing to unlearn and learn.
  • Avoid recruiting testers with lot of experience in independent manual testing teams. Start looking for testers who are good at test automation and good functional knowledge (learn-ability)
  • Do not have the wrong notion that excellence is linked to experience. Many highly experienced people can become a liability in the agile world.
  • Agile will not solve any of your problems just by implementing a agile framework. Agile will start exposing the weak areas where you need improvement, and these inputs can be easily mistaken as problems of agile when they are actually the problems of the organization/team. Agile will expose the problem areas very fast and it is up to you to address them. That means you get more time to recover and improve. That is the real benefit.

How many of you can really appreciate the airline staff, when the flight is delayed?. Once I reached the airport, they said my flight is delayed by four hours. I got annoyed first. Then I checked the reason. They said the break system have an issue. Immediately I appreciated them for detecting it before take off. A failure detected early. As a sponsor of agile initiative, if you have that kind of a mindset, please embrace it. You must be willing to celebrate a failed early sprint and throw a party for the team for their honesty.  When you go to the gym, what you get first is body pain. If continue it despite the initial pains, then you develop muscles, and you can lift more. That is a good investment.