Application Of Organizational Behavior At

Organizational level Assignment # 3

By

Ashis R Nayak 10/27/2014

Course: Weekend MBA BMGT 513 Organizational Behavior

By

Paul Thurston

This assignment is to apply the organizational behavior concepts learned to bring the changes at

Organizational level. The Situation described below is related to my real experience. To hide

identity of the characters and organization, the name has been changed or not mentioned.

`2

Contents

Introduction: ............................................................................................................................................... 3

Is My Iceberg Melting? ........................................................................................................................... 3

Create a Sense of Urgency ...................................................................................................................... 3

Surface the Facts ..................................................................................................................................... 5

The Change ............................................................................................................................................. 6

Barrier to Change: 2 .......................................................................................................................... 6

Why do we have to make this change now? ....................................................................................... 6

Vision & Strategy ........................................................................................................................................ 7

Planning: How to make this happen ........................................................................................................... 7

Communicate:......................................................................................................................................... 7

Upward communication: 6 .................................................................................................................. 8

Downward communication 7............................................................................................................... 8

Forming the team ................................................................................................................................... 8

Prototyping ............................................................................................................................................. 8

Plan for persistence: ................................................................................................................................... 9

Feedback Section ...................................................................................................................................... 10

Reviewer#1 ........................................................................................................................................... 10

Reviewer#2 ........................................................................................................................................... 10

Conclusion Section .................................................................................................................................... 11

`3

Introduction:

This assignment is about applying the Organizational Behavior concept towards the

Organizational Changes.

Is My Iceberg Melting?

I joined a new organization six of months before, in a traditional large size IT Project, with

150 head count T&M contract for a health care government initiative, where first phase of

development completed a year before and working on further phase of development under a

fresh management team. The management is more focused on the next phase of development and

the earlier phase of defect fix.

I observed there in a management report some part showing some numbers which is quite

strange and huge, in no time I figure out that is production support area. This caught my attention

to know about this in depth.

Is this a very low hanging fruit and nobody want to look at this? Further in couple of

meetings I heard a lot of buzz around this but somehow this is been pushed to the last buckets, as

there is no effective way of handling this. This is a usual operational part after the Software

development phase, once development finished and warranty period finished should be handed

over to operation team for the production support activity to address continuous changes and the

request or any break fix or maintenance of the product.

Create a Sense of Urgency

My previous experience on couple of production support projects helped me to gather and

quantitatively presenting the fact to the upper management.

** The Structure of the assignment follows the John Kotter’s Our Iceberg is melting concept of the changes

`4

0

20

40

60

80

100

120

140

160

180

200

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

# Ticket Open 5 33 20 52 56 69 50 92 83 67 72 107 75 99 82 131 107 83 118 94 86 160 140 130 123 112 121 184 172 147 87

# Ticket Open

Incident Open Trend

1314 13851459153716201707

17981895

19962103

22162335

24612593

27322878

30333196

33673548

3738

0

500

1000

1500

2000

2500

3000

3500

4000

32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 51

Tick

et B

ackl

og

Week Number

Series2

Projected Backlog By Dec 2014

`5

Gathering Quantitative Facts

Surface the Facts

I represented the below facts with above statistics in one of the project meeting with all the required

stakeholders to gather their attention.

Everyone had all the common statements “this is known facts “ “why we need to do this now”, “we are

working on this”, “no process defined “, last but not the least “this is not my bucket”.

Currently there is no separate dedicated team to handle any such Service requests or Incident

The resource utilization is not tracked because no accountability and response (RACI) model *1

There is no certain definition for prioritization of these tickets. Ambiguity in the goal.

No classification of tickets. All the tickets known as incident where as most of the tickets include

service request either from issuer or the customer , hence there is no classification of the fix we

are providing

There is no monitoring and controlling mechanism or any responsible/accountable person to track

them towards closure.

There are no artifacts which can be use as part of Knowledge base for future production support

knowledge database.

There is no streamlined process to hand-over this knowledge in between the teams.

*1: Blokdijk, Gerard (2008). The Service Level Agreement SLA Guide - SLA Book, Templates for Service Level Management and Service Level

Agreement Forms. Fast and Easy Way to Write Your SLA. Lulu. p. 81. ISBN 1-921523-62-X.

`6

The Change

The challenge in front of the management was “how to drive ahead to form a production support team,

increase the productivity and enhance the business opportunity?”

Barrier to Change: 2

Team Resistance: 3 There is a perception in the IT industry is that Production support is a

monotonous work and there is nothing to learn in that type of jobs hence growth in those types of

projects are stagnant. With this perception there could be chances of attrition rate increase in the

team.

Uncommitted management and skepticism about reform:4 The major resistance was from the

existing team leads/ managers as the fear disseminate of breaking apart the team or to loosing the

area of control, which was also making the knowledge transition difficult.

Difficulty in doing “Out of Box“ thinking & resources tied up in Legacy System : As I

mentioned earlier everyone is busy in the development life cycle

No one in authority to push the Changes: No RACI 1(Responsible – Accountable – Consulted –

Informed) model defined to drive this change.

Adopting process for controlling and monitoring and put review at each step to gain the

productivity and effectiveness and continuous process improvement, the traditional development

do not follow the process.

Why do we have to make this change now?

As of now the client is focused on the development and little worried on the support side, as when

the major development will finish there will be shift in the focus. There might be loss in the trust.

The number of tickets are accumulating at a rate that this will touch the mark 4000 by December

2014 hence it may go up if no preventive major was taken in time and may be at a time it will be

difficult to manage. Also there is no bucketing of the ticket in terms of request and incidents

(break down of the System) may result into a perception of the poor quality of delivery.

This also is a business opportunity for our organization as well in terms of gaining revenue and

extending the contract for future business in terms of the production support.

*2, 3, 4: Process Mapping, Process Improvement and Process Management By Dan Madison ISBN-13: 978-I-932828-04-7

`7

The proactive communication and clear representation will strengthen our chances of winning the

bid for this production support project in future and will keep the trust of the client, to retain the

client.

Vision & Strategy To create a service focused production support team by adhering to the ITIL concept of the

lifecycle for IT service management (ITSM) 5.

Planning: How to make this happen

Communicate: Effective Communication is the powerful weapon to win the negotiation.

`8

Upward communication: 6

I believe before jumping into the changes few things need to be brought into the discussion with senior

management about this change.

Vision

Strategy

Goals (short term and long term)

Expectation from the changes

Barriers to changes

Time

Cost

Customer impacts

Resource impacts

Known and unknown Risks

Downward communication 7

The affected leads and team members are skeptical about the changes hence they need to be approached

as well to make this change happen.

Clearly express the vision, offer a desirable destination

Kill the rumors by communicating within the team individually

Motivate the members to achieving the compelling vision

Get the buy in and win the trust by honoring their past achievements

Forming the team Assign the Project Manger with a strong leadership to drive the changes and authorize him/her to

bring the changes

Select the team members from the existing team and mix up with the new joinee

Gather the artifacts and prepare strong knowledge base with the team effort

Co-locate the team to increase the self efficacy

Define the Ground rule

Prototyping Identify the prototype area, where the concept can be applied successfully. In this case it seems

incident management sounds more proximate area where this concept can be applies easily.

*6, 7 : Essential of Organizational Behavior, 12th Edition , By Stephen P. Robbins and Timothy A. Judge

`9

The main process steps are: 8

Incident Identification and Logging

Classification and Prioritization

Investigation and Diagnosis

Resolution and Recovery

Incident Closure

Closely monitor and report the statistics weekly, how this new process helps in improving the

previous number in terms of productivity.

Plan for persistence: Present the data to client

Sign the legal contract with the client

Apply on the ITIL concept in other area to improve the productivity such as Service

Request Management, Change Management, Problem Management and

configuration Management

Record the best practices and apply the same in other accounts and future projects

Motivate the team to work on the process improvement with innovative ideas.

*8 : ITIL V3 Concept of Incident management

`10

Feedback Section

Reviewer#1 Reviewer Name: Vivek Gupta

Role in the Organization: Asst. Project Manager

Feedback: This paper is clearly explained how people do not want change in what they are doing and

comfortable with. The problem is evident that at the current stage when production support should be

important aspect of the project as development is more or less is over, production support (Keeping it

Running) is done in development mode (i.e. we know the issue but someone else has to deal with it).

But here change agent has to be higher management and not team member/leader or project manager, to

lay down the production support processes, division of work appropriately. It's best to let the customer

know and let them help drive the process of moving up to the next mode as development can no longer

keep going at large scale.

Certainly, clarity of job duties (Support/development), proven change management processes (i.e.

Incident management, interaction management etc), correct mix of resources, rotation of resources

challenge etc, few thing could be helpful in keeping project team interest in the project and change.

Reviewer#2 Reviewer Name: Om Prakash Roy

Role in the Organization: Ex Team lead

Feedback

Change in the process should be triggered and validated by quantitative analysis.

Team building strategy should be aligned to the overall project goal.

In a big IT project team communication is important part of overall strategy and goal of the project.

Collective decision making towards change of existing process is needed to smooth transition from

development phase to production support.

`11

Conclusion Section

I am somewhat disagree with Vivek’s feedback, on bringing the changes only by the higher management.

The people, who are basically at the ground level, are well aware about their environment and ground

reality. Though the legal/contractual decision and the enforcement for the changes should always be

driven by the higher management but presenting the fact can be come from any level of the organization

where there is an open door culture exist. If we keep on thinking someone from outside will come and

help us and rescue from all the firefighting then by the time it may be too late. I read somewhere “it is not

mandatory to bring the change need to be a manager, rather he/she should have traits of a visionary/leader

to bring the changes and it can be from any part of the organization”.

I agree to Om’s feedback that the transition should be smooth from development to the production

support, as I earlier said the knowledge base is the back bone of the production support, that can only be

achieved through the smooth transition, I have broadly outlined this strategy of the team forming as

“Select the team members from the existing team and mix up with the new joinee”.

Also Om emphasized on the communication which is important in bringing change, I agree to this,

effective and repetitive communication is essential to catch the attention and to motive the team to act on

the changes.

I believe this strategy will work here but to keep the momentum of continuous process improvement team

and management should work in a cohesive manner with a defined strategy and plan. The defined

standards as ITIL I have advocated in my assignment here is a well known standard for the service

management will be well fit to this scenario.