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

 

 

Mentoring someone with imposter syndrome

Found this HBR article very useful. At times, I am also suffering from this syndrome. May be, I am not alone in this. Most of us would have undergone this at some point or other.

https://hbr.org/2019/02/mentoring-someone-with-imposter-syndrome

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

Chekutty from Kerala

Hats off to social entrepreneurs Gopi and Lakshmi for implementing the brilliant idea of creating chekutty dolls from the handloom sarees and clothes destroyed by the Kerala floods 2018. They could raise considerable amount of money to help the weavers who lost their looms and stock. True story of grit and big hearts. Gopi is one person who visited us in person during Kerala floods 2018, just to say Hello to us,…which I can never forget. Wish him great success. I have a chekutty in my car. Since I know the origins of chekutty, and understand the trauma of the floods because we experienced it first hand, and the unity and the fighting spirit we demonstrated as a community during the flood, I have a special bonding to the chekutty doll and the project.

 

Stakeholder analysis to identify key performance indicators of project success

Step#1 Identify the stakeholders of the project / product  (sample list below)

  • Sponsors
  • Portfolio managers
  • Program managers
  • Project managers
  • Owners
  • Engineering mangers / teams
  • Design teams
  • Sub contractors
  • Procurement team
  • Quality team
  • Risk management team
  • Change management team
  • Safety management team
  • Cost controllers
  • Finance
  • Sales & Marketing
  • Project management office
  • Competitors
  • Consultants
  • End users
  • Government agencies
  • Industry bodies
  • Environment safety
  • Quantity surveyors
  • Competitors   etc..

2. Classify them into the segments of;

  1. High power, High interest
  2. High power, Low interest
  3. Low power, High interest
  4. Low power, Low interest

 

3. Identify the key parameters they would like to track towards meeting the project goals of their interest.

The following diagram depicts a stakeholder classification and the probable project parameters they would like to track

BCG for project health

 

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

 

Japanese agency stops funding for Bullet train project

While teaching project management it is very interesting for me to teach stakeholder management where as it is not that interesting when it is about  ‘enterprise environmental factors’. One of today’s main news item is about the stoppage funding of the bullet train project by Modi, because the project team did not address the farmers grievances (fair compensation for the farmlands lost to this project). From a professional project management perspective, this is a very interesting case which combines stakeholder management and enterprise environmental factors.

Anybody who is affected positively or negatively by doing a project or by delaying a project or by not doing a project falls into the category of project stakeholders. Any thing that can affect a project like culture, national holidays, business rules, ethics, environmental regulations, waste disposal norms, working hours, trade union norms are all examples of enterprise environmental factors.   It will be very interesting to identify the key stakeholders of this bullet train project, and analyze how the enterprise environmental factors affect the decision making and stakeholder management.

Business today link 

National Herald

India times 

Lessons from a crowdfunding social service project

We started a crowdfunding project to construct a home for a family whose house got washed away during the Kerala floods 2018. This was our first experience in a crowdfunding project. Here are the lessons we learnt out of this project. 

Credibility of the idea and the promoters are the key success factors for every crowdfunding project.

Credibility of the promoters is the most difficult to achieve. It has to be built over a long period of credible track record.

During execution phase of the project, trust of all the stakeholders have to be built by bringing in absolute transparency of the project (funding, expenses, project progress, project risks, forecasts of time and cost). This is achieved through continuous communication. We used whats-app group, facebook page and the wordpress blog for this purpose.

Probability of scope creep is much higher in crowd funding projects, as the expectations of the beneficiaries escalate during the project execution, when they understand that it is funded by multiple people , hence the illusion that there is plenty of money.

There has to be a key project manager, who owns the entire project, and accountable to the sponsors.

For one of our projects, we started raising funds from people. Then another sponsor who was willing to sponsor the entire project turned up, scuttling our initiative to generate public interest in the project. In fact we started receiving donations for this project and we had to get the permission from the donors to use the funds for another similar project. Getting a single sponsor is good for the beneficiary and at the same time it is a risk for crowd funding.

Ensure that the beneficiary have not sought / applied or is eligible for any alternative funding, before going for crowd funding. Other wise it will lead to point 6. Sometimes we will be preventing a better opportunity (funding) by linking them to your crowdfunding project. There are many larger sponsors out there. So please check whether the project under consideration is eligible for any other source of funding.

Funds have to be distributed against the milestone completion only. Pay it directly to the vendors and service providers. Do not entrust money to the project beneficiary, as it can be misused.

If we are constructing a new house, the risk is very low compared to demolishing an existing house, as the ownership of raising sufficient finding to complete construction falls on the project manager. In such cases, do not even start without sufficient funding required to complete the project.

In new constructions, we have the freedom to start developing and show progress as soon as funds start coming in. This in turn will generate more interest among the sponsors, resulting in better funding.

We started with one project (home for a person whose house was washed away during the floods) based on impulse and intuition. That gave us more confidence to venture into the second project, and the funnel is growing. It would have been better if we had managed it as a program, with a standard design, bill of material, budgeting and funding for the program, than for individual projects. In this case we could have raised funds against the program, instead of individual projects.

Hope to come out with more lessons learned as we progress further.

Visit the crowdfunding project web site 

Organizational structures and their impact on stakeholder management

Organizational structures can be broadly classified into;

  • Functional organization
  • Matrix organization
    • Strong matrix
    • Weak matrix
    • Balanced matrix
  • Projectized organization
  • Composite organization

Functional organization

Most of the manufacturing / service organizations are divided functionally. Each function will have a head, who in turn reports to the CEO. For example an automobile manufacturer will have functions  like;

  • Manufacturing
  • Sales & Marketing
  • Research and development
  • Procurement
  • Finance
  • Human resources etc..

Each of these functions are headed by a senior manager (functional managers), who in turn report to the CEO.

Matrix Organization 

In matrix organizations, the team members report to more than one boss. Team members may report to the project manager for the project related activities, and to the functional manager for specific function related activities. For example, a technical architect in a project may report to the project manager for project related activities and at the same time report to the Chief Technology officer (CTO) for technology related stuff. Most of the product companies, which calls for multi-disciplinary skills to develop the product of the project falls into this category.  Matrix organizations are further subdivided into;

  • Strong matrix (Project managers have more authority than the functional managers)
  • Weak matrix (Functional managers have more authority than the project managers)
  • Balanced matrix (Both the functional manager and the project manager have the same authority levels.

Projectized organizations

In projectized organizations, whatever they do is a project. For example; I.T projects companies, Civil projects companies etc. They perform projects after projects. Project manager and the teams are the breadwinners of the organization. Project managers have maximum authority levels in projectized organizations. In projectized organizations, all other functions play the support role to the project.

Composite organizations 

Composite organizations have a combination of functional, matrix and projectized structure.

A through understanding of the stakeholder’s (customers, suppliers and your own organization) organizational structures will help in accurate mapping of the stakeholders into;

  • High power – high interest
  • High power – low interest
  • Low power –  high interest
  • Low power – low interest

Examples

  • Project managers in functional organizations have very low authority levels
  • Functional managers have more authority than the project managers in functional organizations
  • Project managers have maximum authority in projectized organizations
  • In matrix organizations, the power of the project manager and the functional manager varies based on whether it is a ;
    • Strong matrix
    • Weak matrix
    • Balanced matrix

This knowledge will help us to go beyond what is drafted in the contractual documents and manage key stakeholders very effectively.

The following videos explains this further