Tag: Change Management

From the Sponsor’s Desk – People Don’t Buy What You Do, They Buy Why You Do It

Written by Drew Davison on October 25, 2017. Posted in Articles. 4 Comments on From the Sponsor’s Desk – People Don’t Buy What You Do, They Buy Why You Do It

“Corporate culture matters. How management chooses to treat its people impacts everything – for better or for worse.”
– Simon Sinek – Author, motivational speaker and marketing consultant

If you’re involved in change, as a sponsor, project or change leader, a champion or a target, you know two things for certain; the changes led by great, inspiring leaders are invariably wonderful experiences and, changes lead by the other kind of leaders can be dismal affairs.

As change agents, it’s vital that we understand what it means to be a great, inspiring leader. Simon Sinek’s quote above provides part of the answer. Culture is a key enabler. But how does a leader build the culture that delivers wonderful experiences? Sinek has an answer for that too – “People don’t buy what you do, they buy why you do it.”

In this story, we’ll look at a company with an incredible history of sustained growth and innovation, led by a man who had a passion for people. His motivation? To care for his families, both personal and corporate. If you’re not a CEO, you might be thinking, this doesn’t apply to you. And you’d be wrong. These days, if you’re leading or involved in a change in any way, there will usually be hundreds, if not thousands, of people affected by what you’re doing – your teammates, your customers, suppliers, partners, staff in affected organizations, regulatory agencies, IT experts, security staff, auditors, financial types, and so on. You need to think like your change’s CEO. The more you know about being an inspiring leader, the greater the opportunity to deliver wonderful experiences for all involved. Isn’t that something to strive for?

Thanks to A.B. for the details on this story.

The subject of our story, let’s call him Roy, was the long term CEO of a construction company which had operations across North America. The company grew from a small operation forty years ago to thousands of employees today through smart acquisitions and organic growth. It was hugely successful in a tough, often cutthroat business. It was at the forefront of innovations in constructions practices and equipment development and evolution. It was always profitable and never laid off staff, in both good times and bad. It could count on significant repeat business from its public and private sector clients because of the competitiveness of its bids and the quality of its solutions.

But what characterized the company and Roy’s leadership most was the human touch. Roy knew almost everyone’s name, from the executive ranks to front line workers. When he didn’t know someone’s name, he’d ask. But, instead of first asking what job the person was performing, he’d ask about their family, their spouse, their kids, their hopes and aspirations. Sure, he’d eventually get around to the work discussion, but it was almost always in the context of the family, not the other way around.

He ensured he had lots of frontline contact in his busy schedule. That gave him time to know his people and the opportunity to shape his managers’ approach to the job. Roy always said that nothing was more important than his people. He walked the talk. His approach reminds me of Jim Goodnight, the Co-Founder and CEO of SAS, who once stated, “Ninety-five percent of my assets drive out the gate every evening”.

The culture Roy built in his company was pervasive. So what were the pillars of this empowering culture? There were nine:

Advertisement
[widget id=”custom_html-68″]

Look after the welfare of the family – Roy’s passion was the family – his own, his employees’ families and his corporate family. The work/life balance was zealously guarded. Communications were open, honest, straight forward and as broad ranging as required by the topic under discussion. Roy called one of his managers regarding his wife who had just undergone surgery to find out how she was doing and whether they needed anything. On Christmas day. Hiring focused as much on cultural match as skill fit. The company was consistently ranked as one of the best places to work.
Keep the customer satisfied – Roy’s focus on family carried over to his customers. Even though he was dealing with major public and private organizations and their senior executives, he treated them as extended family, looking after their welfare, their needs and their concerns. Customer satisfaction scores were almost always stellar.
Ensure the company’s success – You can’t safeguard the welfare of your family if the company isn’t a going concern. So Roy made sure that the company took the decisions, both long term and short term, to ensure his family members would always have a place to be engaged and valued. The corporate focus was on continuity, not just money.
Engage from the executive suite to the front lines – Roy ensured that his values were mirrored by his managers. When new projects were started, when new equipment was acquired, when new practices were implemented, when a smaller company was acquired, Roy and his local management team were there, engaging with and listening to front line staff. Everyone was on a first name basis. Discussions were held in the construction zones and local field trailers over coffee and sandwiches or pizza, in hard hats and safety boots.
Provide opportunities for growth – One of the key drivers for new projects and new acquisitions was staff opportunity. Roy recognized that his people needed the chance to build new skills and capabilities to keep them interested and challenged. That focus resulted in an amazing number of long service employees with in depth knowledge of company operations. It was great for the staff and great for the organization. Staff turnover was ridiculously low.
Obsess about safety – Construction sites are dangerous places with lots of heavy equipment and materials and often precarious or uncertain footing. Safety was a constant obsession in the planning and construction phases. When accidents did occur, management and front line staff reviewed the circumstances of the incident, changed equipment and revised their practices accordingly. Their record of safety was exemplary.
Provide good pay, benefits, bonuses and recognition – The company’s compensation package was competitive but not top quartile. However, staff were rewarded for contributions above and beyond through bonuses and recognition in the company’s various media sources. As well, an active employee suggestion system (remember those?) encouraged outside-the-box thinking and provided handsome rewards to successful submitters. And Roy thanked every submitter personally.
Engage in the community – Roy encouraged local participation in every community where the company had a presence. That could include involvement in charity events or support for local community services or facilities. The targeted events were selected locally and carried out locally by company staff. Over the years, they raised millions of dollars for good causes, increased community ties and built corporate camaraderie. And strengthened the family.
Be a leader in best practice and technology deployment – One of the key contributors to company success, providing opportunities for growth and delivering a safe working environment was a corporate obsession with best practices and the best equipment and technology for the job. The company was an early and continuous adopter on many fronts. Management and front line staff relished the opportunities provided.

These nine pillars used by Roy and his company can be leveraged by sponsors, project managers and change leaders to help their “families” survive and thrive. Will they make a difference? Absolutely! As vital contributors to team effectiveness, these nine pillars can help deliver an order of magnitude improvement in performance. But remember what Simon Sinek observed – “People don’t buy what you do, they buy why you do it.” Roy’s experience proves the point.

So, put these points on your checklist of things to consider, become an inspiring leader and deliver wonderful experiences for all. Also remember, use Project Pre-Check’s three building blocks covering the key stakeholder group (including the key stakeholder roles), the decision management process and Decision Framework best practices right up front so you don’t overlook these key success factors.

Finally, thanks to everyone who has willingly shared their experiences for presentation in this blog. Everyone benefits. First time contributors get a copy of one of my books. Readers get insights they can apply to their own unique circumstances. So, if you have a project experience, good, bad and everything in between, send me the details and we’ll chat. I’ll write it up and, when you’re happy with the results, Project Times will post it so others can learn from your insights. Thanks

Change in 7 Questions

Written by Peter de Jager on October 18, 2017. Posted in Articles. 8 Comments on Change in 7 Questions

What must we do to bring about a Change initiative as smoothly as possible? Communicate! Communicate! Communicate!

How much, and for how long do we do this? Until we get sick and tired of the sound of our own voice – then we take a deep breath and a drink of water and we start all over again.

Communication isn’t something that stops and starts; it’s a constant activity before, during and after any Change initiative.

This isn’t exactly news. We sort of get this. Ask any audience to tell you the ‘secret’ to good Change and they will repeat back “Communicate, Communicate and Communicate some more!” as if it was forcefully injected into their cerebellum. The problem arises when the questioning becomes a bit more detailed, “What exactly should we communicate?”

The response to that question is usually either a blank stare or the reasonable recitation of the reporter’s standby; Who, What, Where, When, How and Why. Not a bad start. If we’re writing a news article, then these are good solid questions. The Change Management problem requires all of those, and a few others besides. It’s not that the reporter’s questions are a poor tool; it’s just that they don’t directly address the peculiar psychology of the Change challenge.

For what it’s worth? Here’s a carefully selected of questions specific to Change Management. If we take the time to answer these, then we’ve covered the bulk of the key concerns of those facing the Change we’re contemplating.

1) Why?

This is the winner, the key question; it’s almost the only question worth discussing. If someone asks me to move from one side of the room to the other, or to stop using system ‘X’ in lieu of system ‘Y’, my response is always the same. “Why?” Understanding why a Change is necessary is the most important question we have about any Change. Without a good answer? We’re reluctant to do anything different.

There are lots of good answers to the “Why?” question. One good one is “Trust”. If I trust you and you ask me to do something? My Trust in you might suffice to prompt me to Change. If that Trust doesn’t exist? Then the reason for Change had better convince me, or I’m not moving from where I am.

2) WIIFM (What’s in it for me?)

The Fly in the ointment for many organizations, “It’s not about you!” they cry as they bend over backwards to avoid answering this question. Here’s the newsflash, as long as the users are concerned about the WIIFM question? They don’t pay attention to any other information, more precisely? Until that WIIFM question is recognized they can’t pay attention to anything else.

The best way to think of the WIIFM question is as a nasty, viscous guard dog, blocking the gate to our attention. Until that dog is thrown a bone? No information about the Change, sometimes not even the answers to the “Why?” question, are getting through to our reasoning process.

Even if we honestly have no information about the WIIFM question? We must still acknowledge that the question exists and that as soon as we do have more information, we’ll get back to the audience.

Advertisement
[widget id=”custom_html-68″]

3) Monday?

Assume for the moment we have returned from our strategic planning weekend, with a wondrous, phenomenal vision of the future of our organization. Also assume for the moment that our ability, to convince everyone that this is indeed the direction in which our organization should move, is up to the task. Assume that we’re silver tongued devils and get everyone onboard, on the bus, bought in and generally all fired up. With me so far?

Now they have a question. What do we do differently, specifically and precisely on Monday (or next Friday…or next month… ) to start moving us towards the promised land of milk and ever flowing honey?

It’s a fair question. If we want people to Change, we must describe what they’re going to do differently in terms that everyone can understand. If we can’t? Then we go back to the drawing board, our vision is flawed and unattainable.

4) Won’t?

What won’t Change? What will remain the same during this Change?

The problem here is that when we face a Change, all we see are the unknowns, we lose sight of the fact that only one ‘small’ part of our Status Quo is going to flux. That the rest of our surroundings will likely remain the same.

For example? When the accounting system is going to Change, we’re still going to report to the same boss, earn the same paycheque, receive the same benefits etc. In fact, most of our Status Quo will remain the same. This works for nearly all Change, the only time everything Changes is when we die, and then? It’s not our problem anymore. In nearly all other cases? Regardless of the size of the Change, nearly everything else remains the same.

5) Might?

What might go wrong during this Change? And… what contingency plans have we put in place to mitigate those risks?

The worst thing we can do when heading into the uncertainty of Change is to insist that nothing can go wrong. That’s not only asking for the Gods (and Murphy) to pay attention to us, but it also communicates to those around us that we haven’t really thought this through. Although? If we’re looking for a sure fire way to lose the Trust of those who follow us? Insisting, “Nothing will go wrong” is a wonderfully effective strategy.

6) Will?

What’s going to hurt?

Change Hurts. That’s almost the First Law of Change. If we’re doing something significantly different, then we’re going to be at the bottom of the learning curve. Even if we pay close attention to training, and support, and fall back positions, we’re going to make mistakes, production will decline, and we’ll get things wrong.

If we pretend that the Change will be painless, that it will be “Transparent to the User”, then people will know we’re lying, or at least overly optimistic.

7) Signposts?

Change doesn’t always happen quickly, sometimes it’s slow, almost glacial in nature – we need some way of measuring our progress towards a goal. Without feedback? We lose both the motivation and the will to make sacrifices to move forward. The question on the table is, “How do we know we’re succeeding in our efforts?”

These aren’t the only questions we need to answer during a Change, but they’re crucial ones and if the answers aren’t forthcoming? Neither will the Change. Stick them on the wall in front of you when crafting a Change message and ask, “Am I answering these? If not? Why Not?”

Rescuing A Project, Part Two

Written by Stephan Bals on September 18, 2017. Posted in Articles. 2 Comments on Rescuing A Project, Part Two

For those of you reading this part two of my article on Project Rescue Management: welcome back. For the new readers amongst you: welcome.

After having read part one you may have asked yourself “why would anyone need a project rescue process or an experienced Project Rescue Manager?”.

The question is logical but the following facts will tell you more about the need for such a process and such a type of professionals:

When I did a lookup for the words “project problems” on Google, I got a screen showing there are (at least) +23 700 000 pages found; the sheer amount of discussion on problems around project management indicates that some heavy problems exist and a structured approach to solving such problems is needed;
When we look at the financial impact on regional economies (e.g. the USA or the EU-region) the estimated financial size of problems around (IT-related) projects gone bad is simply staggering

“One estimate of IT failure rates is between 5% and 15%, which represents a loss of $50 billion to $150 billion per year in the United States. Another study estimated that IT project failures cost the European Union €142 billion in 2004.”
(Source: Gallup (2012)

The estimate given above is based on research from 2004 as you probably read yourself if you looked up the article I am quoting from. And those figures are only the estimated financials. They do not include negative psychological, public/commercial impacts or costs of other types of impacts and their associated monetary value.

This short introduction alone shows you why Project Rescue Management is a thing to be thought about.

It could also be worth thinking about from a commercial aspect. A consultancy organization could for example define a new and very disruptive business line: making projects gone bad right again….

If THAT is not disruptive, I don’t know what else is.

My position is: it needs to be done. How? By orienting ourselves much more on the benefits of what needs to be done or what we should not do and why, a.k.a. Business Case Development and Business Case Management. And making sure that selected projects are – based on their business case – ordered and aligned to company strategy. Strategic alignment to organizational goals alone gives projects a better chance of success (by 54% at least as some research by the PMI stated some time back).

But we need a new type of project managers (and managers) with new skillsets to get this cultural shift started towards Business Case Driven Project and Program Management done (“BCDP^2M”, copyright S. Bals, 2017). I already mentioned some personality traits and characteristics such project managers should have. They will also need new skillsets. Which ones? I take the liberty to quote again from mr. Kerzner’s book “Project Management Metrics, KPI’s and Dashboards” (Publish. John Wiley & Sons, 2013(C), ISBN 978-1-118-52466-4, page 3):

Business Analyst Skills or Business Management (*)
Program Management (*)
Business Processes (*)
Managing Complex Projects (*)
Six Sigma
Risk Management (*)

(*: I actually received some very negative comments about my additional areas of knowledge and experience ; in a job interview some time back I got accused of being “more of a business analyst or business consultant than a project or program manager; but as it turns out, when you look at the shortlist above, those skills are exactly some of the plus-knowledge-packages a good PM or PgM should have nowadays….)

Some other trainings that could be beneficial for PM’s or PgM’s are also described by mr. Kerzner on the same page:

Establishing metrics and KPI’s
Dashboard design
How to perform feasibility studies and cost-benefits analysis
Business analysis
Business case development
How to validate and revalidate project assumptions
Establishing project governance
Managing multiple stakeholders
How to develop coping skills and stress management skills

Note the emphasis on business analysis, process analysis, cost-benefits analysis, business analysis, business case development. I add here that business case management should also be included to the list.

In short: the emphasis lies on the business, it’s processes and a business case for the project (or program) aligned to the strategy of the organization.

That’s also why in project rescue management the business case remains a leading document. THE leading document if you ask me.

Let’s talk some more on how to get on with a project rescue. On the following pages, you will find he first two steps in a six-step process (or nine steps if you prefer to really go step by step, sometimes that’s useful).

0. Initiate

Before we continue I would like to give you a bit of a view of the standard Project Rescue Plan I have grown fond of using.

(Copyright Stephan Bals, not to be used, stored in any form, distributed in any form without authorization of the author)

Advertisement
[widget id=”custom_html-68″]

I use this slide to show this to my potential customer/employer when discussing Project Rescue Management and later during the definition of Project Rescue Mandate. Consider it like a place holder, based upon which you can explain to your potential customer/employer what the different stages are and describe at high level what your customer/employer will get per stage. It’s always handy to show you know what you are talking about.

As you can see in the slide, phase 0 is the Initiation Phase.

During this phase, no mandate for work has been signed yet, expectations have not been made 100% clear. That comes after the Mandate Stage. This is like a “meet and greet”-stage for candidates for the Project Rescue Manager role. It’s is just you as the shortlisted candidate Project Rescue Manager and (a) representative(s) from the company wanting to hire your services having a meeting and discussing on a high level what the problem is during the first meeting. Don’t drill down too deep on the problem(s) yet, you will be doing a lot more of that when you as Project Rescue Manager have obtained your signed Mandate.¹

You as the potential Project Rescue Manager and the potential customer are getting to know each other, discuss your cv, discuss work you have done before and possibly you will be asked to share a couple of references your potential customer can check.

A first interview like this – in recent times – most of the time starts via phone-chat with a recruiter. I say “don’t”. If you can, you – as the owner of the troubled project (or program) -should at least meet via Skype of video conferencing but preferably face to face right from the start.

When It comes to meeting that very important person who can possibly help you get your project going again, you as the party looking for that Project Rescue Manager, have a bit of a budget ready for the interview sessions. Like I said, you will preferably want to meet your candidate(s) face to face and they will probably want to see payment for travel costs and possibly one night of hotel costs. And you do not want to look avaricious. Do not be penny wise, pound foolish. Be a good host when inviting your candidates. A well served table builds the biggest smiles and shows appreciation to your guests. First meetings can be short. If you as a potential customer don’t get the right gut feeling about your potential Project Rescue Manager during this short (max. 30mins) talk, thank him/her for her time. If the candidate at the table catches your attention, then talk some more, possibly take them out for a bit of dinner. You as customer/problem owner have little time, but you need to take some time to get to know someone asap.

If you do select some candidates, second talks should be held in more detail on the problems requiring a Project Rescue. Also, the second (and third) round of talks can be held on the same day and with different representatives from your organization. Again, for second and/or third talks, have a bit of a budget ready for all the reasons I already mentioned earlier.

1. Mandate

As part of the final selection process, during interviews you as customer/employer will automatically drill down to one candidate. To get there, like I suggested you will have discussed with the two remaining candidates of your selection process. During your last meet-up, you also define and preferably finalize the mandate for your Project Rescue Manager.

Defining this key artefact together will help you in making clear on how you will work together, what levels of autonomy and what obligations the remaining Project Rescue Manager will have. Your Project Rescue Manager should be able to help you shape his/her mandate coming from experience on this kind of work.

The candidate that gives you the feeling – because that is in the end what any decision is based upon – he/she is working together with you on a well-defined and usable Project Rescue Mandate is the one you will select. Logically.

As a customer, be prepared to talk about things disgustingly honest. Do not act shocked, do not fake false pride. You and your selection board cannot afford it and your Project Rescue Manager cannot afford it. Every day not used well is after all spent burning money for no purpose.

How honest can you expect? Let me give an example of something that happened with one of my clients. I remember one occasion a long time ago, having arrived at the final selection moment, I looked my client in the eye and clearly stated that I wanted the following lines added to the Rescue Mandate: “if any party involved at the decision-making level from your side lies or deliberately gives wrong facts, figures or any other kind of wrong information or bad cooperation I will walk away without having any further contractual or other legally binding obligations to you as my client and this will be the [sum of money] you will pay me without delay if the company is at the cause of my departure coming from not following this agreement”. The gentleman that sat across the table from me blinked, but after a couple of seconds simply said “understood, agreed and so noted in the mandate” and wrote it down.

This gentleman became a friend of mine and still is a good friend of mine now many years later. Was I brutal? Was I – in the eyes of certain readers – possible a bit rude? I do not think so. I wanted to see and feel how this gentleman and the board behind him would react if I gave direct, blunt opinion, feedback, statements or questions.

This gentleman and his board reacted correctly. By giving an honest reply. Would I have stayed if he had said “not acceptable” and he had motivated his reply in an honest way?

Yes. Because my aim was testing the honesty-level. I just wanted to point out (again): being honest in Project Rescue Management will have big paybacks!

During the definition of the Project Rescue Mandate also discuss other items that may be of Interest to your Project Rescue Manager. For example: access to personnel files of team members, access to contracts with suppliers and/or other external 3rd parties and so on. Decide and register in the mandate on these and any other valuable topic that comes to mind what your Project Rescue Manager can/needs/will have access to. Think for example, of the project business case, project status reports, risk reports, board meeting memo’s, the last version of the signed project SOW, number of changes, project assumptions, project quality reviews, test information or any other documents that apply.

Your Project Rescue Manager should be able to give you a list.

Also, as Project Rescue Manager you should have the right to interview anyone involved in the project, external or internal, high or low, without this having any consequence towards individuals being interviewed.

Also, decide on how many team members your Project Rescue Manager will want to add.

And do not forget to talk on the current status of the project! (frozen, partially frozen, continuing? And why?)

2. Analyze

The customer has selected the Project Rescue Manager and a signed Mandate is now on the table. We move on to stage two. This stage – to my modest opinion – falls in to three subparts.

A. Meet, greet and learn

We can make this bit as long and as difficult as we want, but beauty lies in simplicity and love is fed by honesty and loyalty. So, let us keep things short and sweet here.

Your (s)elected candidate will right from day one need to be announced, introduced to a large number of people and shown around. As to the meeting and greeting part, it is nothing less than professionalism if you from the customer-side have prepared a list of people (with a picture if possible) for your Project Rescue Manager to meet and greet. This could have been prepared during the Project Rescue Manager Selection and Mandate Process. Make someone available to support him/her during the first two weeks, if but a couple of hours a day. I would even go so far as to advise you as the higher-up who hired the Project Rescue Manager that you show him around to key people yourself. It is a good opportunity for you as higher-up to have some face-time with the work floor.

It will also be of interest to have the list of project meetings, locations, persons attending, time & days of week already available including access to project documentation from start to current date, teams, team compositions, phone numbers, email addresses, availability and location and contact information of decision makers, stakeholders, customers, 3rd party contacts, team members, PM’s, line managers, functional managers, et cetera. To name but a few information topics that might come in handy right from the start.

Elements such as having a desk or office space and all the usual stuff as a cell phone and a laptop should also have been taken care of right from the start of course. I always like to have a meeting room available for my use on the job in which at least 8 to 10 people can be present, work, or even have a chat amongst each other when needed and which has working video conferencing and phone in place. Bad Managers would call it a War Room. I hate war rooms. The very word brings an image of negative pressures and bad energies. I prefer to call it a Safe Room. What is said in confidence in this room stays in this room. People need to feel safe in this room.

But back to business. Your Project Rescue Manager will need such a room to be able to read, meet and talk with people, if not but simply think.

B. Analyze

You have decided on the information to be available to the Project Rescue Manager. Now make that information available.

I for example want to understand the following:

what is the customer company culture and what is/are the cultures in 3rd parties involved?
Was the plan and number of deliverables, PBS, WBS, capacities, benefits unrealistic/overestimated, meaning: did the project have to deliver too much in too short an amount of time? Why?
Was this project of personal or political importance to someone or did the whole organization stand to benefit from this project?
If any external parties are involved, how is the relation between customer and 3rd party/parties? and why? Duration of that relation?
from a business case perspective, what is purpose of the project, what departments or division(s) will it influence, what products, capacities, benefits in support of what capacities, products, services will it deliver to meet desired strategic outcomes, and is the business case still valid, do we need to adjust deliverables and outcomes, or do we simply need to scrap it?
what performance indicators have been selected, used for this project and why?
was/is benefits management in place and does it play an active part in the project?
how has the project been doing up to now?
was there a process for change control and a CAB (Change Advisory Board)?
was the CAB also responsible for OCM (Organizational Change Management) activities that where related to the project?
What was the level of autonomy of the CAB?
was there a Customer Involvement (sub-)plan of what activities customer representatives will be involved with, when, how many, locations, levels and number of supports from the project team (or a separate sub-project team), trainings, purpose, group descriptions and roles attending, et cetera? If no, why? If yes, where is this (sub-)plan? Who owns it and drives it (from supplier and/or internal to the customer)?
Have we received all weekly, monthly. half year reports and/or deep dive reports?
what problems have arisen on the project on the whole and what actions have taken to solve these problems up to now? (to be asked at different levels to capture different views)
having a good look at RAID-logs, who owns what, what was done, when was it done, what where the effects of what was done?
was the Project Board involved, supporting or just bullying (honesty ….. but it does happen)
how many change requests came, how many where approved/denied/why, scope/time/cost?, how many times was the project base line and project budget adjusted?
how many team member changes happened, how many Project Board member changes happened, how many times was the project manager changed, and why?
do stakeholders still believe and support the project? If yes, why? If not, why?
how is the project team structure organized? Partially onsite, some nearshore, some offshore? How many team changes (members, team size, et cetera) happened per location? And why?
Are there any corporate directives on cost reductions on our side or third party side that influenced the project? And why did such directives come in to view?
In what phase is the project currently? Is anything being worked on or is it in “full freeze”? And why?
What are the performance indicators used?, who selected them and why?
what was the workload per team member? And per team? How much overtime did team members put in and the team overall?
How were team members treated? (internal and external team members alike)
How regular was overwork for (certain) team members?
How are team members holding up? (happy, unhappy? why?)
How where business/customer project team members treated? Why?
Has the difference in “people-management-approach” per type of team led to additional annoyances? Why?
How is risk management set up?
is there a PMO involved or not? what is the role of the PMO and its level of support and influence?
what is the project complexity and why?
what is the level of commercial/political/strategic need for this project in the organization and why? (it’s a good question to ask certain decision makers and stakeholders besides getting answers to this one from revisiting the business case)
What was the level of autonomy of the Project Manager(s)? (or Program Manager(s))
what type of project management methodology(-ies) was used? Why?
How did people (customer, supplier, others) react to working within this(/these) type(/s) of project management methodology?
Would another type of project management methodology (or (mix of) methodologies) have been better suited for this project and why?
How where Project (or Program) Manager(s) treated? (as equals, as “simply do what you are told”, as valued colleagues who were also consulted on problems, issues, risks, improvements on how to do things better?)
…….

You could decide to split up these questions in certain categories. I do. For sure you will not ask these questions to everyone. For example: a Project Board member may not be asked all the questions a project team member will be asked. I divide my questions in to categories, but I take the liberty of not showing you an example of such here, since you may have your own lists.

I will tell you my favored way of getting the answers to most of these questions. In some cases, it’s just getting hold of the numbers and/or documents. But on people matters, it’s always best to do a representative number of one on one interviews. The Safe Room where the Project Rescue Manager works is probably the best place. People can talk in safety, away from prying eyes and ears or interruptions from others.

As to the above displayed list of questions, and some of them might sound double, these are but a handful of questions I (and my team members, when I appoint more people depending on the sizing of the work at hand) need answers to. I actually have quite a list that I like to go through. This is information. Based upon information I can build a picture of the project as it came to be, started, had its lifecycle up to this moment where I appeared and if the project still has a valid business case after having been reanalyzed itself, what possible trade-offs that need to be negotiated and what chances such possible trade-offs have of being accepted or not.

This is a lot of work that needs to be done in a short time. It is especially a lot of work for one person. Which again is why your Project Rescue Manager will need all the support he/she asks for (including the budget and the autonomy to install an assisting team to the Project Rescue Manager when called for), especially the cooperation coming from you as the customer.

C. The First Draft Rescue Plan

During this Second phase (that should last no longer than one to a maximum of four weeks (depending on the size and complexity of the project it could take twice as long), he/she (and his/her selected team) will take in all this information made available per the mandate (and maybe more) and your Project Rescue Manager should also build and present a Draft Rescue Approach Plan that will last up to the GO-stage. At least after two weeks it should be clear what parts of the project or even the project on the whole should be frozen, continued, partially continued for now.

But as to the first draft Rescue Approach Plan, like I said before, I usually use my time-line slide and build on that. But the Rescue Approach Plan needs to be built in more detail. In four weeks’ time at the most (again depending on the size and complexity of the project), it should at least have a clear definition of the Analyze, Initial Report, Evaluate/Adjust/Agree and Go stages, things required per stage (types of information and/or actions) and deliverables (from the Project Rescue Manager, project team, decision makers, customers, suppliers or other teams). People that need to deliver part(s) of the Rescue Project Plan should be held to their obligation without delay or excuse. The Project Rescue Manager will also have drafts of the Rescue RAID Log, Communications Plan, Team groupings and activities, and a draft financial plan up to the Go-Stage.

One should also have revisited the Business Case for the project during the first two weeks and a report on the status of the Business case should coincide with the delivery of the first Project Rescue Report. More about this later.

It is also imperative this stage to formally(!) decide on a Project Rescue Board. Your Project Rescue Manager may not have all the information yet to choose the best formation, so some blanks are logical. But during working between Project Rescue Manager and customer, names & roles & responsibilities must become visible. Fill in the blanks during the Analyze stage. Your Project Board may or may not contain members of the original project board. Remember: you are in a rescue situation. Other influencers and/or decision makers might be beneficial to the project being rescued. Why? Because simply speaking, there are gatherers and there are hunters and there are protectors.… I’m sure you understand the difference.

But you will need a Project Rescue Board with the right people on board. Project Rescue Management is not something you do alone. It is also never about doing a bit more of the same thing with the same people in the same way that got your project in the mess it is in.
You will need people with power in the right places to help you out. It is just simply so that at the same time when considering this, you also need to consider that the people on the “old” project board might not be the right people to be involved in the rescue.

For now we have arrived at the end of part two.

I will show you more steps in the process in part three of this article, coming soon.

As before, if you have remarks, suggestions, or need help on a project rescue, you can reach me at [email protected].

1 Please remember for later: no Mandate, no work! If the customer says they have selected you, make them write an email to you confirming that on the spot, containing price, a timeline and a “breach of contract” set of rules. If you are experienced in this game, you can bring your standard terms to the table for quicker discussion

From the Sponsor’s Desk – Conquering Culture Clash

Written by Drew Davison on September 5, 2017. Posted in Articles. 2 Comments on From the Sponsor’s Desk – Conquering Culture Clash

“We are far more united and have far more in common with each other than things that divide us”

Jo Cox
British Labour MP
22 June 1974 – 16 June 2016

Culture clashes are occurring the world over. In Britain, Europe, North America, the Middle East, Asia and Africa, confrontations between cultures are often the new normal. So too in the business world. Organizations in search of the best and brightest bring people together from all over the globe to work together. Sometimes the result is not what was hoped for. Often the culprit is culture clash – the inability of people from different cultures and backgrounds to work together effectively. So how do we conquer culture clash?

In this story, we’ll look at one person’s journey from project and change management consultant to trainer and ambassador for cultural collaboration. What started out as a request from one business leader to help solve a cultural conflict on one technology team ended up with over fifty training sessions for over one thousand people in North and South America. The accolades from all quarters suggest the program was a success. Attendees acquired new frames of reference to help conquer culture clashes in their worlds going forward.

The Situation

Rekha Kulshreshtha was an experienced project and change management consultant. She was working on a change management assignment when her client approached her with a request to address a potential cultural conflict on one of the teams on a major business change he was sponsoring.

The client had encountered a problem on a previous project that cost him the services of a talented East Indian technician. He was recruited because of his unique skill set after a long search. He was flown to the North American firm’s headquarters, provided with a motel room close to the office, introduced to his leader and teammates and given a standard company orientation. Two days later, the technician informed the company he wished to return home. It seems two problems were at the core of his request: he was a vegetarian in a meat loving city and couldn’t determine what was suitable for him to eat and, he didn’t know how to use the phone to call home. His culture made asking for help inappropriate. He didn’t want to offend.

The client wanted to pre-empt a repeat occurrence on this project. The project was much bigger. The number of offshore staff was much larger. The risks were far greater. So he asked Rekha to take on the challenge. Rekha was born in India and moved to North America when she was six. Often she was the only non-white student in her school. She knew how North Americans tended to react to people who looked and spoke differently. She could also empathize with those who were from away. So Rekha said yes to the challenge.

The Goal

With her client’s collaboration, Rekha established the following goal: to ensure that team members have the environment, knowledge and tools to prevent and/or overcome barriers to effective communication. Emphasis was to be placed on but not limited to cultural perspectives.

The Project

Rekha was an experienced change management consultant. She looked at her change management plan but found the new assignment didn’t fit. She came to the conclusion that providing a framework to achieve her goal was a separate and distinct deliverable. She believed a short targeted course was the answer. She proposed her solution to her client. He agreed.

Rekha wasn’t an educator. However, she had prepared and run innumerable workshops and project reviews in her career so she decided to tackle the course development herself. After all, she had personally experienced the cultural divide. So, she researched. She developed and borrowed material. She trialed and revised accordingly. Finally she had a course she thought was ready for prime time.

The Course was based on a number of principles:

It had to be interactive
It had to have a Goldilocks duration – no more than three hours
It had to be accessible locally and remotely
It had to be suitable for any culture or mix of cultures
It had to feature stories – Rekha’s as well as the attendees
It had to leave participants feeling confident about their abilities to adapt to most communication challenges, one on one and in group settings

Advertisement
[widget id=”custom_html-68″]

The core of the course was the Cultural Dimensions chart below:

The dimensions and spectrums Rekha chose were sufficiently broad to generate discussion, tales of personal experiences and provide insights into the approaches one could use to avoid or remedy a communication problem. And so Rekha proceeded to deliver the first course.

The Results

The first course was delivered to eighty team members. There was no offshore staff involved. Rekha used examples from her own experience to get the discussions going. And then the flood gates opened. One after another, the attendees would recount an experience, a culture clash. They were often about misunderstandings with someone from the same community, with the same cultural background.

Rekha explained to me, “Although the intention of our course was to help people from different countries communicate with each other more effectively, what we really focused on was the basic elements of ‘teaming’. And actually we used stories like the difference between a visit with a hair-dresser (long term relationship) versus a used car dealer (short term transaction) to emphasize that even within our country and culture, there are behaviours across the spectrum and we experience and accept these differences. Once we get people to see the spectrum of behaviours within our own culture, it’s easier to understand that these behaviours exist in other cultures as well.” As Rekha observed, “culture is about generalizations. Never assume everyone is going to be the same”.

After more than fifty courses on two continents involving over one thousand participants, both locally and remotely, the course has received over 80% positive response. Participants are usually bubbling with insight and enthusiasm at the end. Clients have been universally positive. Their feedback suggests that all teams that have been through the course seem to perform at a higher level, offshore members or not. I’d say Rekha and her clients have indeed managed to conquer culture clash.

How a Great Leader Succeeded

I met Rekha virtually, through Linkedin. I asked if she had any stories to share. And here we are. Her success is due to a number of factors including the following:

Outside the Box Thinking – Rekha’s success was due, in part, to her realization that the client’s request was a separate and unique challenge. You know the old saying, “if all you have is a hammer, everything looks like a nail”. Rekha didn’t fall into that trap. She recognized that the problem identified by her client needed a different approach even though it was outside her comfort zone.
Credentials – Rekha was an experienced project and change management consultant. She was also Indian born and Canadian raised. She brought that insight and experience to the development of the course and the delivery of the material.
Supportive Clients – like all changes of this magnitude, Rekha wouldn’t have been successful without the leadership and passion of her client, the corporation’s CIO. He was open, honest and collaborative and he owned the program. When one of the project managers suggested the first offering of the course should be cancelled because the risks were too high, the CIO just said keep going.
Collaboration – Rekha consulted widely, with managers, project teams, change management and organizational development experts, educators and culture change pros. She begged, borrowed and adapted as the needs dictated.
Iterative development – Rekha recorded lessons learned from each course offering using the formal assessments submitted as well as her own recollections and reactions. The course evolved over time and Rekha’s ability to adapt the content and delivery progressed as well.
Time – the two hours Rekha required for the course was ideal. It was short enough that it was tough to say no to. The content she was able to cover was sufficiently compelling and consumable to be retained by the attendees well after the course finished.

So, be a Great Leader. Put these points on your checklist of things to consider so you too can improve team communication and performance. If you’d like more information about the course, contact Rekha directly at [email protected] And if you’d like to understand your own cultural tendencies and how they compare with different country profiles, take a look at Country Navigator. And remember, use Project Pre-Check’s three building blocks covering the key stakeholder group (including the key stakeholder roles), the decision management process and Decision Framework best practices right up front so you don’t overlook these key success factors.

Rescuing A Project, Part One

Written by Stephan Bals on August 16, 2017. Posted in Articles. 3 Comments on Rescuing A Project, Part One

“How do you go about saving a project that has gone bad?”. I get this question a couple of times a year. And yes, it is true.

Over the years I have been active in the areas of management, business improvement/business change, project management and program management, and I have indeed been called in to take over on projects (and programs) that had gone bad. And I have built a bit of reputation for turning bad projects in to “successful projects” if not at least “projects that went from bad to having delivered (most of the) benefits”. It is also true that over the years I have devised ideas on how to start and push towards a project and program recovery.

Since the question has been put to me so many times over the years I decided to write an article about it and post it here to give some insight in to the world of Rescue Project Management or at least to give a view on how Project Rescue could be approached from a real-life-practice-experience .

The way I have written this article is so that I have tried to give you an angle of view on the different parties involved. I hope it works out for you as the reader.

Before you start reading this article, I need to tell you up front: I am a very strong believer that there is no project without a sound business case. And that goes especially for a program. Before any project (or program) is started, there should be a clear business case which relates in a clear way to the strategy of your company or organization. If you don’t have a business case, my advice is: start nothing. Having a business case will – at the very least – help you and all your stakeholders and decision makers do a lot of work without a lot of politics. And PLEASE: make it a business case that sticks. If it does not have figures but a lot of loose statements, throw it out and (again) kill the project.

I once had a manager who, when asked how he his business case had been built, looked me in the eye, smiled and walked away laughing. In short: do not go to work without a business case.

Another thing I firmly believe in is this: yes, your Project Rescue Manager should have extensive experience in project management. But this is not the only thing he/she needs to have. He or she needs to on the one side “fit in with your organization” for say 50% but at the same time needs to stand out or “be a bit different” from your kind of employees and culture. This is because the Project Rescue Manager that will come do his/her thing for you will need to fit in, understand your business on a high level, but should not adhere to ways of thinking and doing and behaving as you expect from your “standard employees”.

He/She is there to generate movement and result(s). And generation of movement, or call it change, is not done by adding more of the same…
So do not just draw up a list of competencies and skills he/she should possess like you do with lots of standard job descriptions and profiles. Project Rescue Management is not a standard job. It never will be however much people want to make it sound or look easy for whatever reasons or motives.

Project Rescue Management: Think Before You Act

To start with there are several considerations that must be taken in to account when initiating a Project Rescue. Starting from the point of view that you have built a business case for your project but it still has gone wrong, then think about the following:

Not every project is recoverable, nor should we want to recover certain projects that went wrong; simply continuing with doing what has already gone wrong just so someone can say “we did that one” and claim a + on their annual appraisal can cost too much and may possibly deliver fewer or no benefits at all to all others involved;
On the other hand, certain projects are a “must do”; for example, if you are an insurance company and you need to do a project to meet regulatory/legal obligations then this is a “must do”-project; the risk of not doing that project could mean – worst case – having to close a business line if not – disastrous case – having to close your company doors;
When you do decide to start a Project Rescue, stakeholders and especially decision
makers need to understand that in Project Rescue the aim is no longer to “finish on time”, the aim is to finish the project within a reasonable (renewed) time line whilst at the same time a readjusted but reasonable/acceptable level of benefits can still be achieved for all interested parties such as stakeholders, business users, department heads and other parties expecting to receive a benefit; You will not get everything you wanted anymore; decide what is still acceptable and go for that or kill the project and accept your losses.

Advertisement
[widget id=”custom_html-68″]

Next to these key points you need to understand, again before you start your Project Rescue, there are two golden rules. These golden rules can never be forgotten and should even be registered in the mandate you will write down and agree upon with your Project Rescue Manager:

Honesty and openness is the number 1 golden rule; Project Rescue Managers do not have the easiest of jobs; by the time they come in faith in the project will most of the time already have sunk to levels below any workable level and communications will have deteriorated sometimes to the level of non-existence; trust will need to be rebuilt on all levels due to annoyed teams (angry team members may even have left the proverbial building) and frustrated managers and customers; to achieve any possible chance for success honesty is the key; if you want your project to continue failing then by all means keep your hidden agenda’s hidden, but do not expect your Project Rescue Manager to be successful in any way if this person cannot be fully and directly honest with you nor if you are not willing to be fully and directly honest with him/her; In any case: do not fire your Project Rescue Manager when he/she gets a lot of heat put on him/her shortly after starting his/her job; if this happens consider a) all the trouble you have gone through to find the right person and b)who (as in “individual” or “group of individuals”) is putting all this heat on the Project Rescue Manager and why is this happening?, the answers might be interesting to look in to;
Choose your Project Rescue Manager wisely; choosing a Project Manager who is already an employee within your company may be a good option since this person knows your company, its culture, the people, the processes, the internal politics; on the other hand, if the selected Project Manager has no success in the end it will almost automatically mean his career-death at your organization (something which will no doubt come to her/his mind on being invited to take the position of Project Rescue Manager); on the other hand again when you seek an external Project Rescue Manager this person may not know your Company, its culture, its politics, et cetera; The first type of candidate may fear for his career the second may not know enough about your company;
You probably see that selecting your Project Rescue Manager can easily turn in to a political debate – which the most influential (group of) stakeholder(s) or decision maker(s) will probably win, even when the selected Project Rescue Manager is then not necessarily the best person for the job – and since time is ticking and money is burning away, political debates need to be kept to a minimum. Selection of your Project Rescue Manager needs to be as swift as possible when and if you decide on starting a Rescue Mission.
One can move aside this discussion, make the discussion more objective if we take a number of personality traits and skills of the Project Rescue Manager in mind. Mr. H. Kerzner, Ph.D., is a worldwide authority who gives us a clear view on what we need to feel and have in a Rescue Project Manager. I take the liberty to quote from his book “Project Management Metrics, KPI’s and Dashboards” (Publish. John Wiley & Sons, 2013(C), ISBN 978-1-118-52466-4, page and applaud Mr. Kerzner for pointing out these items so clearly:

Strong political courage and political savvy
A willingness to be totally honest when attacking and reporting the critical issues
Tenacity to succeed even if it requires a change in resources
Understanding that effective recovery is based upon information, not emotions
Ability to deal with stress, personally and with the team

From my side I would like to add that there are of course additional traits and skills one needs in the Project Rescue Manager. Some of these are for example:

People management skills
extremely direct communication skills at all levels, even up to the board room level
the ability to assist decision makers and stakeholders on deciding “what do we really want at the end”, meaning making people decide on “must have” and not on “nice to see a little red star blinking at the bottom of the screen” when there is no need for that “nice to have” or “must have for a good reason but later on the roadmap will do”; at this point don’t necessarily think “minimum viable product” since you might then have a product that does not do what is needed in the end and for which no one will want to pay; ask simply “what do we need done now! ”
analytical skills of project situation and elements
business case building and managing/analysis skills
strong and longtime project management skills
knowledge and especially experience in working with one or more project management methodologies

You as the audience to this article will no doubt have your own list from which items can be added. Please do. But keep the list effective. Too long a list is likely to achieve paralysis by analysis.

But it is not only the Project Rescue Manager that needs certain traits and skills. The same traits and skills should be available in decision makers and key stakeholders to the project. Plan, do, check and act as likeminded people if you want to make your project rescue a success. Quid pro quo!

Once you have shortlisted your possible candidates, you and your selection board will preferably have a maximum of two candidates left. And this is where the real work starts.

END OF PART ONE

In part two of this article I will start explaining to you the steps in a project rescue process.

Thank you for your time and attention. If you have any comments or questions, don’t hesitate to reach out to me at [email protected]

Copyright Notice
The content of this article and the ideas, suggestions, process descriptions are the intellectual property of the author. Nothing in this article may be used, stored, printed, distributed, changed in any way without the written consent of the author. (C 2017)
Special Copyright Notice
Where applicable, information on other authors and their intellectual property have been added to the article. We inform you again that re-use of their materials and intellectual property is prohibited without their consent.