Skip to main content

Tag: Change Management

How to Delegate to Difficult Employees

Written by Christine Sato on . Posted in Articles. 6 Comments on How to Delegate to Difficult Employees

Delegation is an essential part of life, especially in the business world. Whether it’s managing employees, working on a group project, or dividing up tasks among friends or family, you’re going to need to delegate tasks appropriately and efficiently.

The delegating of tasks becomes even more of a challenge when you are working with difficult employees. If you find yourself having to assign work to a difficult employee, make sure to follow these tips to ensure that assigned tasks get completed.

Clear and Concise Directions

It’s common for careless employees to minimize their responsibilities and place blame elsewhere by saying they received unclear directions. In order to make sure they don’t push this back on you, you need to give crystal clear instructions and avoid micromanaging the employee.

When you micromanage an employee, it undermines their confidence and their performance, adding to the disarray. Instead of standing over your employee’s shoulder telling them what they should be doing at each step, you should focus on the intent of the job and give the employee room to explore ways to complete it on their own.

It’s important for it to be clear that you are assigning the responsibility rather than a specific procedure. Give them clear instructions on what the goals, purpose, requirements, and end results need to look like so there can be no other interpretations. Once they have an understanding that they have the responsibility of completing the task and are entrusted, all you will need to do is check in periodically to see if they have any questions or concerns.

Tailor Tasks to Different Personalities

You have probably worked with an employee that is always “too busy” to take on any more tasks. After giving the employee the benefit of the doubt, you are left with three options for delegating effectively. First, you can assign the person tasks more suited toward his or her abilities. If that isn’t an option, you will have to lower your expectations. And lastly, you must minimize the risk of a poor job, especially if you can’t fire the employee.

Get to know your employees. Find out what they love to do and what they do best. You can then pair their unique talents and passions to certain tasks that need to be delegated. A passionate employee does not need supervision and will generate creative solutions to problems all on their own.

Give Ownership of the Task

The most annoying employee is the one that never shows up or is constantly slacking off. If you are dealing with an employee that is inherently lazy, there isn’t much you can do. However, sometimes a lack of interest comes from the person not feeling “ownership” of a task. If the employee has no accountability or stake in the project, they are going to be less likely to invest their efforts fully.

A person will greet a task in one of two ways: with resentment or with pride. To make sure your employee welcomes a job with pride, never delegate responsibilities that everyone knows you should be doing yourself. The tasks you delegate need to be important and need attending to, not just chores you find unpleasant doing. A good rule to follow—never delegate things that you wouldn’t be willing to do yourself if you could.

Tell your employee why you chose them to complete a certain task. Let them know why you think their particular talents are well-suited for the project. Compliments go a long way and will give your employee a sense of being needed and a feeling of purpose.

Set Firm Timelines and Document Everything

You need to be very specific about deadlines when delegating to difficult employees. This is crucial for group assignments or if the troublesome employee’s participation is vital to others progress.

You need to keep track of every conversation you have with a difficult person about delegated duties. Follow up with an email that reiterates what you just discussed. Ensure your employee knows they can come to you for further guidance or questions. By documenting the steps, you take to ensure communication is clear you will be able to have a reference that can back up your claims if your difficult employee fails to do his or her task or tries to shift blame.

Rescuing a Troubled or Failing Project

Written by Barry Currry on . Posted in Articles. 3 Comments on Rescuing a Troubled or Failing Project

Project Managers from time to time are called in to help rescue projects that are failing. Here are a few areas a Project Manager…

could focus on when determining the corrective action needed to bring a project back on track.

Background to the Problem

The first action is to understand why you have been called in to support or help rescue the project– what is the nature of the problem or problems? – Have the issues been defined? What was the trigger that caused the client to take action? How did the client recognize that there was a problem?

What is the project problem statement?

Understanding the background and current situation of the project allows the project manager to formulate a more effective corrective action plan to bring the project back on track. Some questions to ask are:

  • Has the issue been clearly understood?
  • What has lead the client to recognize that there are problems with the project?
  • How is it known that there are problems?
  • What evidence is available? Assume nothing here.

When did the issue first occur?

Understanding the timeline of when issues and problems occurred within the project can also assist in putting together a root cause of the issues and problems the project is facing.

When was the problem first recognized?

When did the project stake holders officially recognize that the project is failing and needed help? When posing this question, it is important to understand the difference between the symptom and the underlying cause. A symptom is the effect of the problem, and although related to the problem, the focus should remain on the reasons behind or the cause of the symptom.

The first symptom may have manifested itself sometime after the root cause event that triggered the symptom. Therefore – How did the problem first manifest itself? What evidence is available to substantiate the claims?

Looking at the key performance indicators of most projects – these include:

  • Schedule
  • Cost
  • Scope

Is the project late on a number of key milestones?

Is the project greatly over budget?

Has the scope of the project changed?

What controls are in place to monitor these KPIs? When were they first flagged and by whom and why?

Understand Key Process Indicators or Project Health Indicators that are used on the project. It is helpful to understand how these indicators are calculated, how frequently they are reported, and the history of indicator results over a period of time.

Previous Action Taken

Previous attempts at taking corrective action should also be fully understood. Ideally, you don’t want to try to take a corrective action that had previously failed. You can also learn as to why corrective actions failed so that that corrective actions that you put in place don’t fail. Some questions to consider:

  • What action has been taken so far?
  • What has been done by whom and when in the initial stage of the investigation into the failing project? This needs to be understood because early action without research or careful thought I have made the issue worse.
  • Has someone recorded what he or she have done and recorded the impact of what he or she have done?

Problem Impact

An another critical component of understanding the project’s current situation is to understand the extent of the project and how the project’s failure to meet expectations is impacting the business. Project failure has a cost to the business and understanding that cost can assist in creating a meaningful response to bring the project back on track. Some questions to consider:

  • What is the impact of the project problems to the business?
  • Where should the project be now in terms of progress?

Additionally, understanding the extent to which the project is off course. In order to make corrective actions, understanding of the projects current deviation from plan is important to understand. Some questions to consider:

  • Where is the project now in terms of percentage complete?
  • Is there are metric available on Earned Value against Planned Value? Are these figures reliable?

Review the Original Objectives and Scope

Before taking corrective actions on a troubled project, a project manager should understand the project’s scope and deliverables. The project charter outlines the scope and deliverables for the project as a starting point, but changes most often have occurred in the scope. Project scope and deliverables might no longer be valid because of changes in the business. Some questions to consider:

  • Are the original Objectives and Scope of the project still valid?
  • Have the objectives and goals of the project changed?
  • Has the scope changed enough to significantly derail the project?

Review the Project Performance to Date in Detail –

List all of the key deliverables, milestones and assess:

  • Where should they be in terms of completion / delivery?
  • Where are they (status)actually in terms of completion / delivery?

Assessment of the original plan against current status in detail is critical, and there is no shortcut to completing this assessment. The assessment will \will take time, and the devil is in the details. There can be a huge number of deliverables in a large project, so this process is not for the faint-hearted.

It is recommended to be as binary (yes or no and complete or not complete answers) as possible during this review so that the results are honest. It is important to note that you will not make any friends during this process so try to take the emotion out of discussions by focussing on the facts. Some clients may hire in external resources with no personal history on the site in order to get to the facts and remove the possibility of any personal influence.

If a task is late or has had to be repeated has this resulted in an increased cost? Is this substantial? How is this being measured on an hourly/daily basis?

The resulting report from this review process will arm you with the factual data from which you can get to the root cause of the problem(s) and re-plan the project to get back on track for a successful outcome.

Project Risks

Review the original project risks to assess if they are still valid. Have the project risks been updated? Are there any new risks that need to be assessed? How will they affect the project? Have any of the original or new risks been realized? Have they had any impact on the project delivery?

Analyze the Data

Are there any patterns emerging from the review data. Using these results – look for patterns such as consistent issues with departments, people, vendors – that are consistently late or repeating tasks not completed correctly.

If there is an obvious pattern with a delivery and this is identified back to a person or a department, look for further evidence. Is the person experienced enough? Are they the right person for the job? Is there role in the project clear to them and everyone else? Are they doing other work that is preventing them from focusing on project work? Are they capable of the work assigned to them? How was this person or department originally assessed for capability? How was individual performance being monitored?

Are there other factors influencing delivery -e.g. personal behaviors, interdependent service inefficiencies, process issues, system issues, late equipment/software material delivery, procurement issues?

Are operations based resources being allocated enough time to work on the project? Has the client prioritized the project to reflect the required delivery times?

The purpose of this analysis should not be a witch hunt but an honest review of the data recorded in order to get to the real issues.

Do not overlook here to review the controls processes if they fail to capture an issue early enough to control the issue.

Report

Produce a report of your work that should include but not be limited to:

  • Background to the Problem
  • Findings
  • Results
  • Conclusion
  • Recommendations

Utilizing the data that you have collected and the conclusions that you have drawn, based on evidence -communicate the results and recommendations to your main point of contact at the client site on a 1:1 basis.

Present the raw facts to them on confidence and seek their advice on:

  • What would they prefer to do next?
  • How should this information be released to the wider audience?

This will be a good measure of the politics on site and how it should be managed. Remember this is the client’s choice on how they wish to manage the situation.

Although it is rare -it is not unknown for clients not to do anything following such an investigation as corporately the “right thing to do” would step on too many toes and may not be the politically correct course of action.

Take Corrective Action

In order to get the project back on track you will need to do the following based on what you have learned:

  • Define the Scope
  • Perform a Project Risk Assessment
  • Re-plan the activities with new milestones
  • Re-work the budget to reflect the new plan
  • Select the project team (typically some original -some new members)
  • Create a proposal outlining the Project be delivered and what will be different his time in order to prevent a recurrence of issues.
  • Make this presentation to the key stakeholders and seek support and approval to move forward.
  • Kick off the project and implement the necessary controls.

Legacy Systems: To Replace or to Not That is the Question

Written by Rahul Ajani on . Posted in Articles. 1 Comment on Legacy Systems: To Replace or to Not That is the Question

Time is the ultimate luxury in business. Yet, several businesses, including market leaders, are taking time mulling over when to replace their IT applications.

There are obvious and not-so-obvious reasons for switching over to cutting edge IT solutions. But with all the good things of new technology, the scale of change and the temporary disruption that it might bring during the transition, along with the cost and the toll it takes on the organization and its resources can be equally big. This article examines reasons why organizations withhold plans for replacing their IT solutions, why they must replace, and when it is the right time to change.

Why the dilemma?

“What is the definition of a legacy system? One that works!” said somebody in satire. That might be the reason why managers face a dilemma about replacing them: it still works. But there’s more to it. Legacy systems have come a long way to entrench themselves almost inextricably in organizations, making managers and investors equally perplexed as to whether and when to replace them. Here’s how:

24/7 Availability

IT systems have become the backbone of businesses. They need to be up and running, constantly. Even a glitch for a day could cost a fortune. If that sounds exaggeration, you might want to read Comair’s story where the failure of their legacy system for one day resulted in a loss of $ 20 million. No wonder, even the idea of replacing the systems might send shivers.

The Black-Box

It’s not uncommon to have black-box type systems: they work wonders, but few understand how, if not nobody. Those few geeks who coded the system or had clues about it might have left long ago, and the documentation might have vanished, too. Things become worse when these black-boxes are mission-critical applications.

It’s tempting to patch up and keep going just a little longer: web services, middleware, mid-tier platforms, virtualization can alleviate several problems and put a modern face on the ancient systems to show off to the customers; all at an attractive cost and much lower a risk – something that would entice any manager.

A lot is on the line: more often than not replacing mission-critical applications is like an organ transplant surgery. Business continuity, reputation, profitability and a lot more is at risk during the transition along with other unexpected project delays, glitches and gray areas that compound the risk and uncertainties.

It’s not just about the system: as they say it, troubles never come alone. Replacing the system is often synonymous with process re-engineering, restructuring, massive training programs, and new skill are all on top of the responsibility of keeping the show going on as usual.

To sum up, it’s the comfort of maintaining the status quo, the stakes involved in the change, the scale of change, and the cost that make the leaders want to live yet another day with the legacy systems; after all, it still works.

Why replace?

Here are some reasons why we don’t replace legacy applications:

Self-Imposed Prison

Business paradigms have transformed and are shifting ceaselessly but adapting legacy systems to new era can be no less than a nightmare. The lack of skills in those dying technologies, the costs involved, and the limitations on the capability of bygone-era-systems prove to shackle managers every time they think of new products or processes. Even the giant players in the market can be seen trapped in the systems that once made them leaders; shackled; they watch agile and innovative startups nibbling away their market share.

Systems Get Outgrown

Just like office buildings, structures, policies. The problem is that most people can’t see that coming. It is easy to notice that the manpower will outgrow office building when the company is expanding, but who pays attention to the systems? Often there are restrictions on the volume of data and processing capacity of old systems. Unknown to nearly everyone, these limitations can be time-bombs waiting to explode during the period of extensive growth.

The Elephant in the Room

In every sense of the phrase. Over the years, the systems evolve to the extent that they lose their agility, require tremendous resources for upkeep, and become more of an obstacle; just like an elephant. And what about the security vulnerabilities? We better recap the meaning of the phrase ‘the elephant in the room’: an obvious problem or risk no one wants to discuss…

They Don’t Like to Communicate

In a bid to stay ahead and stay alive, organizations have to go with newer systems. But when it comes to integration, the old and the new don’t communicate so easily. At times, legacy enthusiast vendors might devote time and provide ‘glue’ code to make them talk easily with newer systems. But you might not be that lucky always.

Nothing Lasts Forever

Those who know the legacy technology might well be grandfathers already. The legacy service providers are already struggling to justify whether they should continue supporting and if yes, how long. On the other hand, young entrepreneurs are disrupting the marketplace with novel concepts. The day when your system might not be supported, or when market factors necessitate to retire them, might well be tomorrow.

As Bill Gates once said, “Business will change in the next ten years more than it has changed in the last fifty years.” Change isn’t just fast, and it will be even faster tomorrow. Replace we must, but the trick is to know when!

When to replace?

Business is a game of value: delivering value to the customers and deriving a value for the investors. Above the value comes the strategy for sustained long-term value. Whether to replace the legacy system or to carry on depends on two factors: its impact on value and its compatibility with strategy. By now you might have realized that there’s no rule of thumb for replacement, but you ought to consider it seriously in some situations.

When It Stops Evolving

When Lehman gave laws of software evolution, he foresaw it back in 1974 that software – just like managers – must continually evolve and develop new capabilities or else face obsoletion. Lehman said that it becomes lesser and lesser satisfactory, but you know that when the software stops evolving, so does the underlying business to a great extent. Now, considering the tech and market revolution of our times, lack of evolution is an assured way to extinction. Look for the signs of a slowdown in the ecosystem that supports your software. The moment you see the loss of expertise, reluctance and delays in support, maintenance and change requests for your system. Better start planning for the replacement.

When It Starts Decaying

Yes, they do. It’s a result of aging and evolution. Over the years a legacy system will gain a lot of orphaned, duplicate, redundant, and less than optimal source-code. You may wonder ‘why?’ Better ask HR department how many developers, analysts, and architects came and went. Better yet ask IT department what were standards of documentation back then. The legacy systems invariably grow fat with broken architecture in it, popularly known as ‘software rot.’ This is the point of no return. Unfortunately, from here any action (or inaction) to improve the system will lead to disasters. Get more inspiration from Royal Bank of Scotland’s story, where they faced multi-million dollar public fiascos due to their rotting system’s meltdowns.

When It Has a Huge Technical Debt

If you haven’t upgraded to version X yet, the costs and risk for upgrading to x+1 would be even higher. Successive upgrades not implemented are a kind of technical debt. And, the bigger this debt, the larger the stakes. At a certain point, it makes more sense to replace the system than to clear this technical debt.

There are many more signs, and they will pour in from everywhere: the application, its ecosystem, the employees, the environment. They all will start sending the signals. It’s not difficult to spot these signs; they are obvious and abundant! When you see them, the time has come! Call it expenditure or call it an investment, there’s no escape from replacement. It’s then your call to decide whether to wake up now or hit the snooze button.

Where There are People, There is Conflict

Written by Usama Shamma on . Posted in Articles. 5 Comments on Where There are People, There is Conflict

Conflict is a mental struggle resulting from incompatible or opposing needs, drives, wishes, and external or internal demands.

Where there are people, there is conflict. Conflicts are seen as negative. However, this is inaccurate as conflicts are necessary for healthy relationships.

Conflict should not be perceived as a problem. It is a chance for growth and can be useful in opening yourself up to groups or other individuals. When conflict begins to suppress or disrupt productivity and gives way to more conflicts, conflict management is needed to address the dispute. There are many types of conflict, but here are three typical examples:

1. Intragroup Conflict

Intragroup conflict occurs among individuals within a team. The incompatibilities and misunderstandings between team members can lead to intragroup conflict. It starts from interpersonal disagreements like team members have different personalities which may lead to tension or differences in views and ideas.

Within a team, conflict can be helpful in coming up with decisions, which will eventually allow them to achieve their objectives as a team. However, if the degree of conflict disrupts harmony among the members, then some serious guidance from a different party will be needed for it to be settled.

2. Interpersonal Conflict

Interpersonal conflict means a conflict between two individuals. Conflict occurs because of differences between individuals. We all have varied personalities which can lead to incompatible choices and opinions. So, it is a natural occurrence which can eventually help in personal growth or develop our relationships with others.

Interpersonal conflict among individuals at work has been shown to be one of the most frequently noted stressors for employees. This type of conflict is associated with the broader concept of workplace harassment. It relates to other stressors that might co-occur, such as role conflict, role ambiguity, and workload. It also relates to strains such as anxiety, depression, physical symptoms, and low levels of job satisfaction. Disputes between peers as well as supervisor and subordinate conflicts fall into this category.

3. Intergroup Conflict

Intergroup conflict occurs when a misunderstanding arises among different teams or groups within an organization.

Horizontal strain intergroup conflict typically can occur between the marketing & sales departments who are looking to increase the organizational sales. Varied sets of goals, objectives, and interests of these groups can cause conflict. Competition between the groups also amplifies intergroup conflict as each organizational team is trying to outperform each other in reaching their set of goals and objectives. These factors may include a rivalry in resources or the boundaries of responsibilities.

Another type is Vertical strain conflict which involves competition between hierarchical levels such as a union versus company management, or a struggle between a group of employees and management.

Conflict Resolution Management Techniques

There are five strategies for managing stressful situations. None of them is a “one-size-fits-all” answer. Choosing the best conflict management technique depends on a variety of factors, including an appraisal of the intensity of the conflict and environmental factors. Here are the five types of conflict resolution management:

  • Collaborating − win/win
  • Compromising − win some/lose some
  • Accommodating − lose/win
  • Competing − win/lose
  • Avoiding − no winners/no losers

Collaborating Technique

This technique follows the rule “I win, you win.” Collaborating means working together by integrating ideas set out by multiple people. The objective here is to find a creative solution acceptable to everyone. It calls for a significant time commitment. Collaborating can lead to “I will win all costs” or the Competing technique below. Each group must be committed to the win/win outcome and have trust with each other for collaborating to be successful. The collaborating approach gives longer lasting and more meaningful agreements. Participants that collaborate are significantly more likely not to feel negative about the outcome.

Compromising Technique

This method follows the rule “You bend, I bend.” Compromising means adjusting with each other’s opinions and ideas, and thinking of a solution where both points of view are part of the solution outcome. Similarly, both the parties need to give up on some of their ideas and should agree with the other. Values and long-term objectives can be derailed using this technique. This process may not work if initial demands are high and if there is no commitment to honor the compromised solutions or outcomes. Comprise is best in tough situations where collaboration will not work. The results are less likely to be sustainable and mutually valued as both sides feel slightly negative about the experience.

Accommodating Technique

This method follows the rule “I lose, you win.” Accommodating means giving up on ideas and thoughts so that the other party wins and the conflict ends. However, using this technique, one’s own ideas do not get attention, ensures lost credibility, and influence is lost. The approach of “I will just do what you say” deflates the morale of one side of the conflict. Accommodating gives a lack of caring, concern, and commitment to the solution outcome by one side of the conflict. It is having one side of the conflict jumping ship and saying “It is your problem now.” Leaving both sides of the conflict feeling negative about the experience and untrusting of each other regarding the solution outcome.

Competing Technique

This method follows the rule “I win, you lose.” Competition means when there is a dispute a person or a group is not willing to collaborate or adjust, but it simply wants the opposite party to lose. This technique can further escalate conflict or losers may retaliate. This “It is my way or the highway” leads to stronger emotions and greater conflict. Many conflicts start as competing but then move into other collaboration types.

Avoiding Technique

This method follows the rule “No winners, no losers.” Avoiding means the ideas suggested by both the parties are rejected. Both parties are then lead undermine each other, ignoring each other’s ideas and creates a greater wedge between the two parties to reach a conclusion in the future.

How Do You Sell Agile to Your Control Partners?

Written by Kiron Bondale on . Posted in Articles. 3 Comments on How Do You Sell Agile to Your Control Partners?

When selling the value of agile transformation, the focus is often on the benefits to the sponsoring business or to delivery team members.

But in most organizations, there are multiple internal stakeholders beyond these who will help or hinder your progress towards becoming agile. Control partners such as Finance or Risk might be skeptical or downright resistant to fundamental changes to delivery approaches.

So how do you sell agile to these stakeholders – what’s in it for them?

Finance

Finance departments want to ensure that the company’s funding resources are being utilized effectively and that good accounting principles such as writing off sunk costs are being practiced. They also want to know that project investment decisions are delivering expected business results. Hence, they are likely to be somewhat leery of approaches which eschew traditional safety blankets such as detailed requirements baselines or multilevel Gantt charts.

Agile delivery focuses on early realization of business value but also early, objective indication of critical issues which can trigger timely project termination decisions. Agile also supports changing the traditional project funding model from full scope commitment to a value-driven tranche approach which can reduce non-value add gold plating or the use of excess project budgets to fund unnecessary PCRs.

Human Resources

HR departments have significant effort invested in tools such as job families and programs such as performance management or individual recognition. The transition of delivery staff from specialists to generalizing specialists as well as the need to recognize teams as much as individuals might concern HR professionals from both a work effort and a attrition risk perspective.

While there is little doubt that there will need to be effort spent in changing the current state, effective agile delivery can result in higher levels of employee engagement and job satisfaction which in turn can reduce common challenges for HR teams such as low employee morale or unplanned time away from work.

The agile journey can also generate other more subtle benefits such as a broader pipeline for leadership talent which results from delivery staff taking on greater ownership for team development and self-organization, as well as better business continuity and succession planning through the cross-training and broader learning that are natural outcomes of becoming generalizing specialists.

Risk

Risk partner concerns with agile delivery relate to the potential impacts of poorly designed or implemented changes as well as the potential change storms which can result if the frequency of changes exceeds stakeholders’ ability to adopt changes.

While these are valid concerns, they assume an undisciplined approach is taken to agile delivery.

Disciplined agile advocates early and regular engagement of key enterprise stakeholders to ensure that a fulsome set of requirements is incorporated into solution design. While continuous deployment might be practiced within non-production domains to reduce implementation windows, this does not imply that the same high frequency must be applied for implementing production changes.

Agile reduces delivery risk by requiring teams to sufficiently explore key areas of technical and operational concern early in the project lifecycle. On traditional projects, such risks rarely get effectively addressed till late in execution phases by which point the organization has expended significant funding and the common response is to throw good money after bad.

Agile also reduces the magnitude of changes through an increased frequency of delivery. Yes, the first implemented change might be significant, but subsequent releases will incrementally evolve capabilities making it easier for operational teams to absorb the changes.

Finally, with a greater emphasis on quality throughout the lifecycle, there is a reduced likelihood of hidden defects which are a common source of operational or reputational risks.

Procurement

Procurement groups will be concerned that earlier engagement of vendors might increase delivery risk due to a lack of a fully detailed requirements baseline. They might also worry that changes to funding approaches will reduce their ability to negotiate cost effective deals with vendors who were used to trading pricing reductions for long-term contracts.

Procurement approaches will need to evolve by moving away from traditional full lifecycle fixed cost contracts to incentive-oriented contracts which encourage vendors to deliver the highest value and highest risk items early and frequently. This can in turn result in a healthier relationship with less procurement headaches as vendors will be less inclined to low ball bids and then use costly project change requests to make their profit.

Agile also increases transparency of vendor delivery through frequent demos, business value milestone-based payments and backlog visibility which will make it easier for procurement teams to administer active contracts.

As with any change, it is crucial to start with answering why it is beneficial to not just the organization as a whole but to individual impacted stakeholders who are needed to support the agile transformation journey.