Author: Sharath Kumar

Sharath Kumar is an enterprise project management consultant for Pcubed, based in London. As a certified project and portfolio management practitioner, he has worked on initiatives with public sector, time-to-market, manufacturing, financial services, energy and nuclear clients. Sharath's advisory experience covers a broad range of services: portfolio optimization, value engineering, change management and IT transformation with a current emphasis on knowledge management. Contact him at sharath.kumar@pcubed.com.

The Accountant and the Project Manager: A Friendly Competition or Intimidation at It’s Worst?”

Introduction Ever wondered why there is stiff competition between an accountant and a Project Manager? Because they are both quite creative: the former with the money, the latter with the work estimates. Humour apart, Project Managers (PMs) are still much sought after as a ridiculously popular profession in today’s industry. Mostly because today’s businesses attempt to squeeze the most margins in revenue while keeping costs low. PMs can make sure that will materialize (or that is the industry’s viewpoint?). I have spent the best part of the last three years managing projects in a global financial firm. Whilst not all of them were a success, none of them were absolute project failures either, as we built a strong network of people along the way. Looking back, one of the key reasons for project success having a clear understanding of the role of empathy and respect for people in a project environment. This allows the PM to step in with his or her team in project execution, and take a step back when needed to see how his or people are really doing in terms of their need for support and their overall aspirations. In one global organization where the revenue model was based around financial businesses, PMs were hired as experts to formalize project environments and implement small specialized projects to big-budget regional projects. One would encounter PMs who were independent contractors, permanent employees as well as management consultants. While this would produce and concoct a heady mix of personalities in the workforce with diverse PM experiences and expertise in methods such as Agile, it would also require collaborative working to meet the firm’s goals. I was in a fortunate position to work with multiple PMs with various functions in the department. While from a serious perspective, we would all work our daylights into making each of our projects a success, there was a humorous and lighter perspective to the environment, which I would like to share. The Monk with a King’s Desire This is a short story of a PM did not want any recognition or compensation for overtime. Nor did he like being recommended for a new project within the department or any praise in his name for his achievements. The person kept a “low profile” by not stepping on the toes of any senior management member. He had a lot of years on him, therefore quite senior in the organization. Tasks or projects in which no one else was interested were assigned to him and he would gladly accept them. This was the set perception, and I gathered that he quite liked it that way. This did not; however, reflect well within his team. Whilst on one of my audits, I heard from one of his colleagues that the person was extremely harsh on his team members. He would not allow them to be recognized or rewarded for their work. Yet no whistle was blown because no one was brave enough to come forward. The person was a senior individual with a decent reputation on the board. One day the PM was briefing one of his team members who stood by his desk blocking the PM’s view to a bright lemon yellow, open-planned office environment. This team member was a relatively big person who resembled a heavyweight wrestler in dimensions. It was the start of the planning cycle, so quite a lot of emphasis was placed on getting the estimates done for the respective projects. Over the brief, the PM started to give the team member a hard time. The team member was pale and scared, as usual, with eyes on the ground while the PM rambled with a heavy breath and a dark tone. A threat was made that if the team member did not achieve his objective, he would not be allowed to go home for the day. Apparently, the PM was notorious for keeping his word. As the hours passed on the day, the pressure built up. People had started to leave for the day. The team member skipped lunch and tea breaks, but did manage to produce a draft of his plan by the end of the day. The PM had long left for the day by then. Next day at the board meeting, the PM presented the draft plan, which was received quite positively. The board thanked him, and he acknowledged the appreciation with a remark that it was part of the job. One voice arose after the applause faded. “Meet me after the meeting.” This was a senior director, the PM’s boss. Soon after the meeting, the PM went religiously straight to the director’s office with a gentle smile of accomplishment on his face. The director remarked on his entry, “Credit goes to the big guy who stood in front of me without whom I wouldn’t have seen how my project is being run today.” The PM’s smile broadened. He thanked him and repeated his words that it was part of his job to do so. To this, the director said that he was really referring to the PM’s team member as the “big guy.” The director further explained that he had stood right behind the team member the previous day, when the PM was giving him a hard time over the brief. Because the guy was so big, the PM couldn’t see his director standing behind him! The PM’s smile was now replaced with a frown accompanied by dancing droplets of sweat in his boss’s cabin. The director further said that his people shouldn’t have to suffer at the cost of projects being managed by severe task masters who positioned themselves to be accomplished PMs. The credit (and the PM’s job) went to the big guy indeed – for being big at heart, and for doing the hard work! The PM was fired from the job and moved to another branch. He was never again seen in the department. The new PM did get a slap on his wrist for not raising the red flag that his PM was too harsh with him and the team. Nevertheless, this was a needed change to the organizational culture at large and the boss understood it was something that couldn’t be achieved overnight. In conclusion From what I have seen and experienced recently, PMs today are pivotal roles especially in project-based organizations pursuing innovation and transformation initiatives. Projects are run at a mad pace. However, even in this situation, one should not lose focus on being a good person. Having empathy and mutual respect for people in the organization will go far in terms of building networks and being successful. As a message to bosses, building perception is the most part of playing the career game, but only if genuine and people-focused, is it sustainable. Like I said, respect and empathy goes a long way the unfair world of highly political organizations.

A Project Engagement That Went Horribly Wrong

An organization had asked us to undertake a Project Server deployment initiative. The user base was gigantic. The deployment timeframe was tight, and on the agreed-upon budget we could just scrape by. The initial kick-off meeting took place in an eerie room where there was a creepy pale white elephant — existing data and its quality. Data was everywhere — the data’s quality had to be assessed and some of it had to be created. The number of stakeholders to be engaged was growing in number and requirements were being agreed to, all leading to a gravely expanding scope. To deploy the enterprise project management (EPM) solution in place, our experts put a lot of hours in — including plenty of blood-curdling non-billable hours to accommodate the work, even as it continued growing in all directions. Everything was done on horrifically tedious Excel sheets and hence the data had to be validated, scrubbed and cleaned up before migrating to the new platform. Custom code had to be written to migrate data, generating rejection errors as the data was in different formats. With every new delay caused by scope creep and inconsistent data, we spawned a new adversary. Of course, the project ran over budget. We had to manage more non-billable time. The lack of a support contract increased frustration of the developers. However, due to a good working relationship with client, we were able to loss-lead on the service and still maintain a dialogue with them. 3 Creepy Lessons We Had to Learn Always manage project scope to avoid scope creep. Make sure you have set this up and agreed in stone with the client in the statement of work. A proper change control process should be in place to manage any changes to the SoW. This will become your garlic necklace and holy cross to ward off any evil scope creep. Service transition is quite important, not just with EPM but with any type of engagement. When handing over the delivered service or solution to the client, ensure there is an agreement in place to provide any support going forward. Having a support contract in place post-engagement will help recognize the support revenue and also formalize turnaround time according to the service level agreement. Finally, do a formal current state assessment to avoid the “tip of the iceberg” horror. Spend enough time on understanding the current infrastructure, build a foundation for technology-enabled change and address the scalability needs of the client’s programs to avoid scary surprises at later stages of the project. Photo courtesy of Christy Henderson

Raphael Thlemard image of Berlin Wall

Breaking the Barrier: How to Set the Groundwork for Change

Change is about winning hearts and minds — and sustaining this win. In order to understand how to manage change, you need to understand resistance to change. Management guru Peter Drucker once said, “I am more interested in knowing about people than businesses.” He understood that it’s actually the people you need to think about when analysing resistance. Across your organization, people in different functions have their own perspectives on the change as well as varying degrees of resistance to change. The measured impacts to change can vary from team to team. It’s not until you examine three factors that play a tug-of-war with resistance that you can start to manage them. What are the three factors? According to Richard Beckhard and Rubin Harris, who published a change formula in the 1970s, these are the crucial elements that drive change: Dissatisfaction with the current state; people within the business must be dissatisfied with the current situation and ready for a change; Attractiveness of the solution being proposed to take the business to the desired state; and Practicality of the steps being planned to accomplish the change. To put these into the form of a formula: (Dissatisfaction x Attractiveness x Practicality) > Resistance to the change Countering resistance requires all of the other factors put together to outweigh it. Let’s look at specific approaches from a high level for responding to and managing (and overcoming) resistance to change. Understand the Causes of Resistance to Change People love their offspring When an individual or a team has developed intellectual property or a method for doing work, it can become precious to them, especially if they’ve been recognised for the achievement of the method. This behaviour can cause people to hold on tight to their inventions when a sweeping change is perceived as threatening to replace the way they work and produce deliverables. The behaviour is especially common within a technology-enabled change project, such as document management or business process re-engineering deployment where specific tools or manual processes invented by people to perform their job are now being replaced by a standard enterprise-wide system. People get comfortable working in silos People get used to working within functional units while interacting with a select chain of others in order to perform their work. Often, their interaction with other functions is virtually non-existent, making the organisation a group of silos. So they may resist an upcoming change such as an enterprise resource program implementation that’s intended to connect and establish interfaces between functions such as human resources, finance and purchasing departments. Risk and fear of loss Uncertainty, fear of failure and fear of job loss will also cause resistance to an upcoming change. Just look at what happens when a car assembly line shifts to robotic arms. Suddenly, the people who work in that plant know some of them will lose their jobs. Unions will go on strike, the media will smell a good story and management needs to gird for a fight. Simple Inertia Causes Resistance to Change Don’t forget Newton’s first law of motion, also called the law of inertia, which states that an object at rest stays at rest and an object in motion stays in motion until it’s acted upon by a different force. In the business environment, when people are in their comfort zones, it’s quite a challenge to have the role of “change agent,” knowing that you’re going to have to be that “difference force.” Know Your Current State; Establish a Reference Before the introduction of a transformation program, a common practice is to perform a formal assessment of the business by involving the leadership. The leadership team needs to work with the change team to engage key stakeholders in order to assess the capacity for change among individuals and business unit levels. This assessment will ask: What factors are causing and will continue to cause resistance to change? Are there processes to support change and are they well defined? Does the organization have an enabling culture for change? What kind of funding, reserves and people are available to support the change? The questions can be asked as part of a detailed questionnaire released to the stakeholder community. The findings from the survey can feed into establishing a baseline or reference for the characteristic features for the change environment. For instance, a financial building society carried this assessment out during a major EPM upgrade programme in order to assess its environment for change. The findings were fed into the assessment tool’s analysis framework. The outcome was the establishment of a reference of all the features and agents that enabled or resisted change and the levels measured in order to provide insight of the current state for leadership’s decision-making. The assessment can be carried out at any time during the change lifecycle; but best practice suggests running it for the first time before the change journey begins. The diagram below, adapted from the Prosci “Flight and Risk Model,” helps identify the stages of increasing fear and resistance as time passes during the lifecycle of the change. Source: Prosci Flight and Risk Model It’s worth noting from the diagram that the variables that affect the scope of change and resistance to change need to be identified and recorded early on in order to give the change team better bargaining power and time to manage the response to change. For instance, if increasing rumours and behaviours of uncertainty are sensed in the organisation during the change assessment, the change team can incorporate a robust communication routine with defined channels and frequency to help engage with the stakeholders on the shared objectives. Effective communication of the change objectives will help ease the ambiguity and spread of rumours. One example I witnessed involved a merger between two companies during which rumours started to fly about a management buy-out and the direction of the business. The amount of uncertainty increased as did attrition. The leadership worked with the integration change team to perform a “current-state” analysis and develop recommendations, which included “all-hands” sessions to bring employees on board with the shared vision of the company. The implementation of this communications drumbeat started to influence the company’s turnover and decreased the number of rumours. I should also mention that the communication and cascade of the shared vision was linked to managerial performance and reward. It was a simple but powerful measure that helped enforce certainty and controlled the changing culture in a positive way. Take Time to Say Why the Change Is Required The output from the process of defining and analysing the current state provides the input to answer the question on the reason for change. However, the business case for change involves detailing the scope and linking the benefits to the costs of the change. A forecast of benefits is needed. Also, the change team should work with senior stakeholders in identifying risks and issues that may arise if this change isn’t implemented. The above elements will help in compiling the case for change. An example. During early stages of an intranet upgrade programme within a professional services organisation, the knowledge management team worked with the stakeholders in gathering pain points from a current state assessment; then it constructed a business case for change with the scope, benefits, concept and next steps highlighted in the case. This was a time-consuming effort that involved rigour in getting an accurate assessment of the current state. However when it was presented to the board and the sponsor, the case proved effective in seeking senior leadership buy-in because it helped clearly understand the link between the benefits of change and the objectives. Seeking a Communication Plan? If you’re unsure what a communication plan for a project should consist of, Bonnie Biafore offers this practical communication plan on MPUG. Support Objectives with a Plan of Implementation During the engagement phase of the change journey, momentum should start to gather. You need to leverage this movement forward through a set of well-defined milestones and specific actions that include the initial steps in implementing the change. It’s a must that these actions align to the overall shared objectives that have been communicated earlier. An initial task plan equipped with a high-level plan and quick wins is absolutely necessary. The plan needs to include input from all agents of the change network and also cover the tasks aligned to the timeline, resource and change milestones. These initial steps pave the way for the stakeholder community to understand the link between the shared objectives and the tasks for making the change a reality. Helping people make that connection between where they are now and how they’ll get to where they’re going helps overcome resistance. The plan also brings together the change team members and the wider circle of stakeholders to feel like they have a role in the change implementation. A sample task plan with timeline, tasks summary and milestones. Remember: The resistance barrier to change is overcome by focusing on three vital factors: Dissatisfaction with current state; Attractiveness of the proposed solution; and How practical the steps are to execution. Each factor represents an opposing force to counter resistance and help bring about successful change. Never underestimate the human aspect in finding success while managing change. Image courtesy of Raphaël Thiémard under a Creative Commons license (CC BY-SA 2.0). Photo cropped for inclusion.