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.

Project stakeholder management

If we can maintain the project stakeholders satisfied throughout the project, then the project is successful. The first step towards this is aggressive stakeholder identification and stakeholder’s expectation management. The positive expectations must be maximized where as the negative expectations must be minimized. While the stakeholder register will vary across projects, the following list contains the most common project stakeholders;

  • The sponsor (the entities funding the project)
  • Project managers (Owner’s PM, Contractor’s PM, Consultant’s PM, Discipline wise PMs)
  • Program managers (If the project under consideration is part of a program)
  • Portfolio managers (If the project under consideration is part of a portfolio)
  • Project management office (PMOs)
  • Consultants
  • Team members
  • Supervisors
  • Equipment manufacturers / Suppliers
  • Procurement management teams
  • Risk management teams
  • Quality management teams
  • Safety department
  • Planning department
  • Competitors
  • Statutory bodies

I am sure that a detailed analysis will extend this list further. If we have to perform a detailed stakeholder analysis, we need to;

  1. Identify the stakeholders
  2. Perform stakeholder analysis
  3. Manage stakeholder engagement in the project

The following two blog post of mine published at  Wrench elaborates these concepts further;

The art of managing project stakeholders – Part 1 

The art of managing project stakeholders – Part 2

 

The output of the stakeholder analysis is the stakeholder classification into the quadrants

stakeholderanalysis

The high power / low interest category of stakeholders must be kept informed about the project progress using a milestone chart (summary level information). The high power / high interest category of stakeholders must get more detailed view of the project at frequent intervals in the form of   Milestone charts, High level schedules, Risk rating matrix, Project ‘S’ Curves etc. The Low power / Low interest category can be ignored. The Low power, High interest category must receive the project progress details at a frequency which will ensure their interest in the project. Very often, the low power – high interest category is very powerful as a segment. For example :- The product review bloggers. They are the opinion leaders, and they must be proactively managed.

Summary

Stakeholder engagement is one of the critical success factors for every project. Project managers must proactively plan for effective stakeholder identification and management throughout the project. Since stakeholders power is directly linked to their organizational structure (functional, strong matrix, weak matrix, balanced matrix, projectized, composite), a proper study of the stakeholder’s positions, and their organizational structures will help in better project risk management and communications management.

pmp_kochi_kerala_india

 

 

Understanding Earned Value Management System (EVMS)

Scope of the project : This project comprises of laying a fence around a square plot of size 1 km on each sides (A,B,C,D). Each side has a budget of 1000. The work is supposed to get over on the 4th week. The surveyor is conducting the survey to assess the progress after 4 weeks from the start date.

Side A, Side B, Side C are fully completed.

The Budgeted Cost of Work Scheduled BCWS(A), which is also known as the Planned Value (PV) for A = 1000

Since ‘A’ got over, the Budgeted Cost of Work Performed BCWP(A), which is also known as Earned Value (EV) for ‘A’  = 1000

The Actual cost (AC) incurred to complete side A = 1000

For SIDE – B,   PV=1000, EV=1000, AC=1000

For SIDE – C, PV=1000, EV=1000,  AC=1000

For SIDE – D, PV=1000, EV=500, AC=800

evm example 1 (1)

EVMBAC (2)

Conclusion 

A Schedule Performance Index (SPI) =>1 indicates the project is doing well schedule wise

A Schedule Performance Index (SPI) < 1, indicates that the project is lagging behind schedule wise

If the Cost Performance Index (CPI) >=1, indicates that the work is getting completed within budget

A Cost Performance Index (CPI) < 1 indicates that we have spend more than planned for the completed work.

Throughout the project if we can maintain a CPI and SPI which is greater than or equal to one, then the project is doing well schedule wise and cost wise. 

The ‘S’ Curve

The ‘S curve’ is widely used in project management to track the project. At regular intervals they plot the Planned Value (PV), Earned Value (EV) and the Actual Cost (AC) . If SPI=1 and CPI=1, then all these curves would have intersected at PV.

Badget-at-Completion-EVM-for-SharePoint

The Budget at Completion (BAC) is the sum of ‘PV’ of all the work from start of the project till the end.

Based on these data, it is possible to forecast the Estimate at Completion (EAC)

EAC = AC + (BAC-EV) / CPI  (Assumption, the nature of the work is same)

 

pmp_kochi_kerala_india

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. 

pmprisks

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.

pmpinjust5weeks

Why traditional project success criteria are still relevant today?

During one of my training programs, a project manager said ‘I am not getting acceptance for my project. What should I do get the acceptance?’. That was a difficult question to answer, considering the fact that I did not know much about his project. Still I wanted to give it a try, and I asked more questions about the probable causes that are acting in favor of project acceptance and the ones acting against project acceptance, just to understand the context better, before trying to help him out, if possible.
The key factors favoring his project’s acceptance

  • The project leadership team, especially the CEO is committed to the project
  • The product quality is excellent.
  • Capability of the team is good.

The key factors opposing his project’s acceptance

  • Organizational politics
  • Fear of loss of job
  • Trade union involvement …

Luckily I asked him about the ‘acceptance criteria’ of the project, which he, his team and all the key stakeholders were trying to achieve, and unfortunately it was not available. Further research reveals that, this is a major problem in many projects. The perception of success varies from project to project, and from stakeholder to stakeholder. There is no agreed upon success criteria for most of the projects, and it is a global project management problem or opportunity!.

Click here for the original blog post

Courtesy : http://www.wrenchsolutions.com

Evolution of ‘project success criteria’

During one of my training programs, a project manager said ‘ I am not getting acceptance for my project. What should I do get the acceptance?’. That was a difficult question to answer, considering the fact that I did not know much about his project. Still I wanted to give it a try, and I asked more questions about the probable causes that are acting in favor of project acceptance and the ones acting against project acceptance, just to understand the context better, before trying to help him out, if possible.

The key factors favoring his project’s acceptance

  • The project leadership team, especially the CEO is committed to the project
  • The product quality is excellent
  • Capability of the team is good

The key factors opposing his project’s acceptance

  • Organizational politics
  • Fear of loss of job
  • Trade union involvement …

Luckily I asked him about the ‘acceptance criteria’ of the project, which he, his team and all the key stakeholders were trying to achieve, and unfortunately it was not available. Further research reveals that, this is a major problem in many projects. The perception of success varies from project to project, and from stakeholder to stakeholder. There is no agreed upon success criteria for most of the projects, and it is a global project management problem or opportunity!.

  • Who has the right to declare success?
  • What are the criteria that will be used to determine success or failure?

Answers to these questions are critical to every project’s success, irrespective of the contract types used.

The definition of ‘project’s success’ is continuously evolving; 

1960 – Technical terms (If the product of the project is working fine, then the project is successful)

1970 – Time, Cost, Quality (Triple constraints)

1980 – Accepted by the customer

1990 – Still more criteria

(Harold Kerzner 2000)

Here is the Project Management Institute’s view of project success as per the Project Management Body of Knowledge (PMBOK Version6), Released in the year 2018 ;

“Traditionally, the project management metrics of time, cost, scope, and quality have been the most important factors in defining the success of a project. More recently, practitioners and scholars have determined that project success should also be measured with consideration toward achievement of the project objectives.”  Ref  Project Management Body of Knowledge (PMBOK) Version 6 

That is a radical shift in the definition of the success criteria of projects. Till recently, the industry believed that a project is successful if it is completed within the agreed upon time, cost and met it’s scope with required quality. As per this definition, the project’s management need not really worry about meeting the end goals of the project.

Kochi metro rail  is a project which got over on time, within the acceptable budget and met the scope with the required quality. Till last year, I believed that it’s project management is extremely successful. Did it meet it’s objectives?. I am doubtful. Since I do not know the pay back period, I am not sure. Did it ease the traffic congestion, “no”, it did not. From that perspective I may have to change my view from ‘success’ to ‘failure’ for this project. And the project manager is accountable.

As we all know, every project delivers unique product or services as it’s output (PMBOK). Based on this, the project success criteria  can be further divided into;

  • Project management success  – Time, Cost, Scope, Quality
  • Product’s success (Effect of the project’s final product)  (Baccarini 1999)

Project Success

Going by the latest view of PMBOK, project is successful if it is completed within the agreed upon time, cost, met it’s scope with required quality  and the benefits forecast used for justifying the project’s initiation is accomplished. The first part (project management success) is accomplished through professional project and program management, where as the product’s success is ensured through project portfolio management and project management combined.

Best practices :

  • Opportunity planning
  • Success criteria document
  • Monitoring stakeholder engagement

In my next blog post, I will elaborate the steps to develop, deploy and maintain the ‘success criteria document’ 

Courtesy : Wrench Solutions 

Contact 

 

 

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

 

Climate Change and India

A classical case for explaining enterprise environmental factors and their impact on projects.

https://wp.me/p54MZb-1wN

How to define project goals – 10 questions one should answer

Whether it is about starting a new blog or building a new airport, before starting the project one has to get convinced about the business case and the viability of the project. Projects fail at the beginning, not at the end. Filtering out the best before investment is the key to avoid failures.

Before starting any new project seek answers to the following 10 questions ;

  1. What is the goal of the project?. Why are we doing it?. What is the problem or opportunity it is trying to address?.
  2. How much it is going to cost by way of money / effort?. This must include both the development cost and the maintenance cost (life cycle cost).
  3. What are the other alternatives to accomplish the same goal. Why are we not considering them? (Alternatives analysis).
  4. Has anyone done a similar project in the past?. Are there any learning from them?
  5. Have you done a cash flow analysis for the project?
  6. How much time is needed to get the initial investment out of the project? (Payback period)
  7. Who all are the key stakeholders of the project?. How are they going to benefit?. What are their roles and responsibilities towards the successfull completion of the project?
  8. What are the major risks?
  9. What are the major assumptions we are making?. Are they validated?
  10. What are the major milestones of the project and the tentative dates? (milestone list, road map)

Monitoring Project Risks: Risky Business

You said it well. If we manage all the risks well, then the project will be successfull and at the same time risk management is risky business. Click the link below to read this very useful article on project risk management.

https://wp.me/p5JWg4-P2