Persuading people

After long time I found something to write on this blog. 馃檪

While I have now kind of moved to full time management, it is essential that I persuade people about my propositions and convince them that they are good for them. Till now my motto is and will be to be as genuine in your intentions as possible. Be very true to yourself and to the person you are interacting with. This is the soul of persuading. I feel if this is not there no matter what I do, the person may not feel good about the choice he made in long run. However, even with good intentions, you need few techniques to save your time spent on convincing people. Here is what wikiHow tell us…

How to Persuade People With Subconscious Techniques – wikiHow

There are lot of related articles which are also interesting.

Developing WBS – Effort vs Result

When we start working at a project we are very focused on the process that we follow. For most of IT projects following waterfall model, phases of the project are quite the same. Requirements, Design, Development, System Testing, Acceptance. Even in large projects, we have a time sequence in forms of iterations, phases and within each phase we follow similar patterns.

Estimations are done before hand based on the high level requirements. Which get refined after the details of requirements in first phase are done. But rarely adjusted for actual work. Glen Alleman writes about confusion between effort and results. This is a good article which explains how to move the focus from effort to actual delivery of the project. What he suggests is to create the WBS based on completing a requirement rather than for a phase of the project. One of the advantage of this is that you can actually get a pretty good view of how much work you have really completed. This also helps you work out the dependencies between various features.

My experience with project management suggests use of UML for requirements management. I used Enterprise Architect UML modeling tool for the same some time back. One of the great use of this tool is to be able to model the requirements and be able to map them with actual code components. This gives us a clear traceability between various components and requirements. So when a change in system is required it is much easier to find the impacted areas.

However, I do not agree with some of the exclusion Glen speaks about. Some WBS activities are required to ensure that the product is delivered and the people issues are also well taken care of. We do need to have a holistic view of the product in the early work. We can not break the WBS in set of features before we have addressed some key architectural issues. Also the tooling required for the project is indicated by the design. If the tool has a wider effect on the project, it needs to be considered in the WBS. But apart from these all other points are very valuable for delivering the product.

Resource Management – a TODO list

Quite some time back, I had listed various aspects of resource management on project. This was really in bulleted list format. But even in this form it is quite usable. Here it is:

Aspects of Resource planning & management

– People Management – Key areas

  • Individual goals
  • Work time restrictions
  • Interpersonal relationships
  • Handling egos & other emotional issues
  • Distinction between long task and avoiding work
  • Distinction between commitment and productivity

– Planning induction of resources in team

  • Identification of resource requirements

o Defining skills required

o Soft skills

Client Communication

Client business understanding

Scope management

o Semi Technical skills

Configuration Management

Defect management

Build Management

Backups & BCP management

o Technology skills

User Interface

Usability

Look & Feel

Scripting

Core components

Data Access

Database

Architecture & Design

  • Working with gaps in skills

o Impact on effort

o Impact on schedule

o Training needs

o Risks

Induction process

  • Raising request for resources

o Within Account

o Delivery Center (DC) level

o Corporate level

  • Assessing resources

o Identify assessors

o Provide clear req. to assessors

o Skill gap analysis

o accepting resource

  • Inducting resources

o Core skill gaps training

o Semi Technical and Soft skills training

  • Planning for identification to induction lead time

o Calculate the lead time

o
Workout the latest date for inducting a resource

  • Contingency plan for delays in getting resources

o Plan for backup resource

– Planning for resource activities

  • Project Core activities
    • Planned activities
    • Team meetings
    • Environment setup
      • Desk allocation
      • Hardware setup
      • Software setup
    • Configuration tool connectivity
      • Source Control setup & folder sharing
      • Initial checkout
      • Daily check-ins
      • Daily build & deployment
    • Client calls
    • Onsite team calls
    • Timesheet
      • Entry
      • Approval
  • Account level activities
    • Conducting Interviews
    • Meetings & trainings
      • Management reviews
      • KSS (Knowledge Sharing Sessions) & Generic trainings
      • Town hall meetings
    • Fun activities
      • Quarterly meets
      • Fun games and team building
  • DC level activities
    • Fire drills
    • Exhibitions, Road shows, Quarterly meets
  • Individual level activities
    • Visa applications
    • Claims, Leaves, Reimbursement applications
    • Goal settings and Appraisals