Wednesday 31 October 2012




A leadership style builds the climate in an organization and a leader is responsible for quality of organization climate which in turn account for about one third of profitability and productivity.

A person behavioral and emotional intelligence aspect has plays a vital role in one's leadership attitude when leading and dealing with people?

Six kind of leadership can be observed. Following is the circle of leadership style .



Different scenario have diverse need of leadership . A leader is in center of this circle where he/she needs to carefully pick the leadership style as per need of time.

Let’s explore what kind of approach or attribute a leadership style has, in what situation it is going to be more effective and when it can cause bad results.











 







Approach:   DO-WHAT- I-SAY or My way or high way

Effectiveness Situation:                                                                                                       
It is effective only in turnaround scenario, while making tough decision like firing and dealing with problem employee with whom everything else has failed or in natural disaster like tsunami , fire etc. A leader has complete control on situation.

Do not use in long overhaul and MUST not be practices once crisis is over.

 Drawback:
What if one continue to stuck with coercive style.

This top down decision making may force employee not to bring new ideas as they thought that it will be killed at first shot. Attitude of just-follow-order will be developed in people . This will kill innovation.   Morale will be down and people will stop taking initiative.

    Overall negative impact on organization climate .


 Approach:     COME-WITH-ME                                       

Destination is told but how to reach there is people decision.

This style provide the vision and making clear to people how their work is useful and how it matters to company and why.

Effectiveness Scenario:

As it is people decision on how to achieve goal , it makes them innovative and motivate for calculates risk. Useful when organization is moving aimlessly and missing or confusing vision and strategy. Authoritative leader provide direction to people . People get motivated and work for one mission which increase productivity.  Overall very positive impact on organization climate.

Drawback:
If working with team members who are more experienced then leader, people can think of leader as self-important and with excessive self-esteem.











Approach: PEOPLE-COME-FIRST

People are more important than tasks & goals. Theses style leaders build the emotional bonding and reap it for productivity.

Effectiveness scenario:

If you are assigned a team with low trust and weary, Affiliative leadership build trust, bring  harmony and energize the people. It is used when team building is needed.

Drawback:

Affilitaive leaders do not provide constructive advice on how to improve and leave employee to figure out the way. When people need directives , affiliative leadership do not provide any navigation. As it has less focus on task, poor performance can go unnoticed or overlooked.











Approach:  WHAT-DO-YOU-THINK

Making decision collectively . Having consensus among people.

Effectiveness Scenario:

Consider that you own a shop and you need to close down it .
There are two ways , just tell the decision , this will cause panic and legal action against organization.
Other is call all employee discuss facts , take their view and build consensus to close down . People will understand the situation and will collaborate and trust will be maintained.
Very helping when leader is uncertain and need expert advice.

Drawback:

It can cause series of meeting with no results .If people are not competent to provide decision making advice.












Approach: DO-AS-I-DO

Sets very high standard and exemplify himself. Pinpoints poor performance and ask to put more effort.

Effectiveness Scenario:

When need to achieve business results quickly e.g. to gain market share by introducing new products before competitors. Organization will have a high energy group people for a short time period with very high productivity and quality of work.

Drawbacks:

People are overwhelmed by demand . Put team in continuous stress which bring the morale down.
Work become task oriented and so routinely that it become boring. It could bring unhealthy competition to get leader attention by people.











Approach:  LET-ME-DEVELOP-YOU

Leader identify people skill set , strength & weakness to develop him/her.

Effectiveness Scenario:

The coaching leadership style is most effective when the employees are receptive to this help. Build a environment where people are happy to share the knowledge and are open to feedbacks.
This will increase productivity as employee’s personal aspiration , long term goals & organization objectives go together.

Drawbacks:

It fails if employee do not want to learn or is not interested in change his or her way and attitude.
To get more of this style a learning atmosphere is needed .




Ø  All images from  http://www.123rf.com
Ø  http://www.money-zine.com/Career-Development/Leadership-Skill/
Ø  http://www.eqleader.net/
Ø  HBR On Managing People
Ø  http://www.managerssuccess.com




Tuesday 25 September 2012

Potential Risks Of Project Management Process



We are going to discuss the in-built risk of some of processes in project management processes defined in PMBOK.

No matter how structured and robust framework available for project management , at the end it is human who is going to execute and we can make mistake.
Let’s explore what are the potential risk associated with processes:




     
     Potential Risk: Missing stakeholder
  • Any missing stakeholder could cause a negative impact on project .Any missed likely to be find later     and when identified they may ask for change and this could cause delay
  • Wrong Classification of stakeholder on influence/power/interest matrix. This matrix is used to evaluate how to manage communication with stakeholders and a wrong interpretation will lead to a weak communication plan and right message will not reach to right person in right time. There could be hundreds of stakeholder and this matrix is very useful in planning strategy on dealing individually or grouping.

 


      Potential Risk: Stakeholder Expectation Management
  • Every stakeholder need one’s requirement to be implemented & Scope creep.  One of the most complex part of project management is managing stakeholder’s expectation. Everyone    wants to have his/her requirement to implement. PM need to balance all requirement from all stakeholder on basis on business case , project charter and prioritization.




      
      Potential Risk: Project Duration Computation
  • Padding is extra time allocated and cost added as sufficient information is not available for estimation .It means there are many unknown region which can cause unknown risk and this increase uncertainties. With many padded estimates , you will lose stakeholder confidence and no one going to trust on schedule developed on such estimation.




    
      Potential Risk: Near Critical Path activities
  • Need to monitor activities of all work packages of critical path & near critical path. More the activities closer to critical path , more the risk to project .A Project manager need to monitor near-critical path activities as for something happens and a near-critical can become critical.If identified late such scenarios and apply Schedule compression tools Fast Tracking & Crashing which has risk of rework and cost respectively.




     
   
Potential Risk: Project Cost accuracy
  •  For better accuracy , estimate should be based on WBS and the person who is going to execute .          Two most important cost to consider are as:
    •    Cost-Of-Quality  : Cost of quality planning of overall project
    •    Reserve    : It includes cost needed to manage all risks (know & unknown risk) of  project



      
Potential Risk: People with wrong skill set,      Motivation
  • Hiring of right people with right competency is the first sign of project success. Every work package  may need some specific skill set to accomplish the activities.People with not sufficient skill set will cause less productivity in turn timeline can be delayed.
  •  Keeping team motivated is very complex as every person has different attitude and behavior.There is need to have a plan for team building activities ,reward & recognition system and conflict management in place to mitigate these risk.

REFERENCES :

Thursday 2 August 2012

Fusion Of Agile Scrum to BDD

Agile methodologies are getting a lot of attention now a days and organizations are keen to adopt the agile for software development.

Scrum is one of the most famous process for agile software development.

It is assumed that readers have sufficient knowledge on Scrum agile process and terminology.

In Scrum, all requirements are listed in Product Backlog in a sprint planning meeting, on top the high priority and at the bottom the ones with lower priority are listed. Team members figure out how many items they can commit to and then create a sprint backlog, which is a list of the tasks to perform during the sprint.
The spring planning is as shown in figure below:

While an agile approach can be used for managing any project, Scrum is ideally suited for projects with rapidly changing or highly emergent requirements such as we find in software development.




When requirements are changing fast, there is risk of misinterpretation of requirements and their functional behavior and also behavior of new requirements.

If there are complex business rule and complex business scenario then risk of fulfillment of requirement goes up with each such business case, adding more risk of acceptance of final product.
This could cause rework and delay in final product shipment and a long product backlog.

In Scrum, after defining the Sprint backlog the development activity ,which is called Sprint, starts . One sprint is usually spans from 24 hour to 30 days.

In such scenario it becomes very important to have clear understanding of requirements as development duration is less and there is very little scope to recover from any rework due to misunderstanding of requirements.




How one can mitigate this risk and can fill the gap between team & product owner to have clear understanding of requirement/functional behavior to develop product as needed?

Behavior-Driven Development (BDD)  is perfect answer to this question .

But wait …
What is this and how it can help?  Let me explain ..

BDD focuses on obtaining a clear understanding of desired software behavior through discussion with stakeholders. Behavior-driven developers use their native language in combination with the ubiquitous language of domain-driven design to describe the purpose and benefit of their code. This allows the developers to focus on why the code should be created, rather than the technical details, and minimizes translation between the technical language in which the code is written and the domain language spoken by the stakeholders  e.g. business, users, stakeholders, project managers etc.

Found this definition kind of language difficult .Lets go into more details and try to understand it together..

Consider the online-store application. User  wants refund in return of defective product.
Requirement from client will be to return the money to the user on refunding some article say phone.

Ok, this is fine but what is needed to implement in software and how client will accept it?

A very obvious question from development team.

This kind of confusion happens because user & developer talks in different language .
Developer talks in technical way and user in their own language for a requirement causing gap in understanding.

                                                                                                                                          
How can it BDD be created so that client and development team are having same understanding.
In BDD language the requirement can be described as:


 
                                                                                                                                                   
                                                                                                                                                               
BDD provides a platform to transform requirement into functional behavior .This results in better understanding of functional behavior of application to both client and development team.

Development team knows what to implement and client knows what to do in acceptance testing.

This was a summary introduction of BDD . There are many other keywords available in BDD for all please google it .



  
And now the million $ question , where to put BDD in a scrum process ?
This is a very important point to utilized the full power of BDD .


The figure above shows all points where BDD can be plug-in to Scrum methodology.
Lets discuss how BDD will be useful on all points …





BDD will provide common ground & language to transform requirement into functional behavior in product backlog and to change functional behavior into technical specification to implement.
  




Many times  Functional behavior are related to each other and in software development, team members work parallel on functional behavior linked to each other
  


In daily scrum meeting ,BDD will provide common platform to understand each of development activity and will avoid any confusion and knowledge gap to produce final among development team.






At Sprint meeting , Product owner , Development team & stakeholder comes together and see a demo what the team has produced .

As BDD is in place from Sprint planning and all stakeholders were involved when defining requirement , BDD documents become the valid document to discuss final product behavior in user acceptance .

This provides a better visibility of what was required , why was needed & who has requested.



How this fusion will benefits ….
  •   Avoids misinterpretation of  user stories
  •   Transform requirement in to functional behavior of the software
  •   Provide a common platform and vocabulary to understand requirement in better way
  •   Development team is aware of User Acceptance behavior in advance for all user stories
  •   As requirements ( user stories )are inter-dependent ,therefore helps in avoiding any confusion among development team
  •   Spring meetings & daily scrum meetings  are more effective
 References :