Sunday, April 05, 2020

Your Project Is Not Disruptive. And That Is OK.

Your Project Is Not Disruptive. And That Is OK.
Innovation means the application of ideas that are novel and useful.

Creativity, the ability to generate novel and useful ideas, is the seed of innovation but unless it’s applied and scaled it’s still just an idea.

Innovation must lead to the introduction of new products and services that add value to your organisation and your clients.

Innovations can be big or small, but breakthrough or disruptive innovation is something that either creates a new category, or changes an existing one dramatically, and obsoletes the existing market leader.

So we need to stop calling everything breakthrough or disruptive, especially in internal company discussions. It is more than OK to have a balanced pipeline of big and small ideas, and we need to get comfortable with that again.

If we demand nothing but disruption or breakthrough, (delivered tomorrow and on small budgets) then that is all people want to work on, and to accommodate this, everything gets labeled in those terms.

But language matters, and once we start calling good but smaller ideas breakthrough, we lower the bar.

This is a recipe for mediocrity, and is one of the reasons why so many companies struggle with too many small initiatives and not enough big ones.

In a nutshell: It is important to have a balanced pipeline of big and small ideas, and we need to get comfortable with that again.

Read more…

Saturday, March 28, 2020

Understanding and Managing Your Project’s Complexity

Understanding and Managing Your Project’s Complexity
One of the main reasons technology projects fail so often is their (underestimated) complexity.

Managing this complexity should be an urgent concern for any organization doing large technology projects.

Stephen Carver, Senior Lecturer at Cranfield School of Management created a simple but very useful tool to assess and help you manage project complexity.

But before we look at the tool and how you can use it, we have to start with some results of the research of Stephen and his team about what complexity actually is.

Not complexity, but complexities...

There is more than one dimension to complexity. Instead of a binary understanding of complexity in projects (it is complex, or it is not) you should be thinking in three dimensions of complexity:

> Structural complexity
> Sociopolitical complexity
> Emergent complexity

Structural Complexity

Structural complexity is associated with size, variety, breadth of scope, the level of interdependence of people or tasks, or the pace of the work.

It is the most easily recognized of the complexities by both practitioners and researchers and is also described as complicatedness or the level of interconnectedness.

The complexity associated with pace can be particularly challenging as the faster the pace, the greater the resource intensity and therefore the more complex the project is to manage. Luckily just for a limited time.

This may be the case, for instance, in a project developing a new piece of consumer electronics. See my article on Cost of Delay that explains why the pace in consumer electronic projects is typically so high.

Sociopolitical Complexity

Sociopolitical complexity is associated with the project’s importance, its people, power, and politics, both within the project team and in the wider stakeholder communities.

The number of stakeholders in a project represents a structural complexity, but their different agendas cause sociopolitical complexity.

Emergent Complexity

Emergent complexity comprises uncertainty and change. Uncertainty is typically the result of novelty of technology or process, a lack of experience, a lack of availability of information, or some combination of these.

Change, on the other hand, is part of any project - including changes in requirements, in technology, in stakeholders, and in the organization itself.

Emergent complexity is identified as a challenge caused by a potential or actual change in either a structural or sociopolitical element.

Complexity Assessment

The three complexities provide a useful high-level classification, but greater granularity is needed to guide discussions about specific complexities and their management.

Therefore Stephen and his team created the Complexity Assessment Tool (CAT), a simple list with 32 yes/no questions, designed to identify the elements of complexity in a project and guide discussion of those elements.

You can view and download the CAT here, and you can download the original research paper here.

In use, the benefits of the CAT arise not directly from the questionnaire but from the subsequent conversations between people involved in the project. The CAT is, in other words, a tool for transparency and sensemaking.

The framing of the elements as statements facilitates the discussion with the team and stakeholders. All of the items are phrased as particular challenges, designed to identify real, significant sources of complexity.

The Emergent Complexity is a result of potential or actual changes in the state of one or more of the 32 items captured by the CAT’s list of statements. As a result, the tool measures emergent complexity differently, capturing it as the number of expected or possible changes in structural or sociopolitical sources of complexity.

For example, managers might agree with the statement that “the budget is sufficient for the task” at the beginning of the project but express uncertainty over potential funding changes that may cause the budget to be insufficient for the task at a later stage.

That uncertainty represents a potential emergent complexity, tracked in the right hand column of the tool by an indication that the element may be unstable and therefore subject to change.

Sociopolitical Complexity is King

One very interesting result of Stephen’s work is that it can also lead to better targeted learning and development activities for managers.

“Structural complexity is hard. The rest of it, now that’s proper hard.”

In a teaching session on complexity, they asked 246 project managers, “In your work, which of the three complexities are the most difficult to manage?”

They then asked the same group, “In your own formal training and development, which of the three complexities has received the most attention?”

The contrast between the complexities they faced and the organizational response through learning and development was clear—the area most project managers (68 percent) found most difficult to deal with was socio political, yet a great majority (87 percent) said their training and development had focused on structural issues.

Having this language for discussion enabled the identification of a significant area for development by the organization.

The capability to manage sociopolitical complexity can be enhanced by development activities that focus on stakeholder engagement, project leadership, and change and communications management.

Many elements of this complexity can be turned to benefit through focusing on relational rather than procedural aspects of management.

In a nutshell: Managing complexity should be an urgent concern for any organization doing large technology projects.

Read more…

Sunday, March 22, 2020

Change Management and Your CAST of Characters

Change Management and Your CAST Of Characters
There is a simple truth about projects. All projects result in change.

Some projects bring about small modifications to the status quo, and others introduce a large-scale transformation.

Many people in many roles will be affected by and instrumental in the change you’re promoting.

It’s important to tend to their needs throughout the change journey.

Here’s the CAST of characters you will meet:

Champions: These are people who want the change and work to gain commitment and resources for it.

Agents: They implement the change. Agents have implementation responsibility through planning and executing. At least part, if not all of change agent performance is evaluated and reinforced on the success of implementing the change.

Sponsors: They authorize, legitimize and demonstrate ownership for the change. Sponsors come in at least two varieties. They possess sufficient organizational power and/or influence to either initiate commitment of resources (Authorizing Sponsor) or they promote the change at the “local” level (Reinforcing Sponsor).

Targets: They are called on to alter their behavior, emotions, and practices. (During the change process, everyone is a Target at one time or another.)

People in different roles have different needs. Staying aware of those roles will help you with your messaging, coalition building, and every other aspect of your change work.

Here are some character rules to help your change to be effective and fast.

> Agents must have trust and credibility with the Sponsors and trust and credibility with the Targets

> In major change, there will always be overlap in the roles. When roles overlap, treat the individual as a Target first. This includes Sponsors.

> Building a cascade of Sponsors at each level of the organisation who each demonstrate commitment by what they Express, Model, and Reinforce is the single most important factor in getting swift implementation and value realization for your change.

> Your change is accelerated when the other three roles (Agents, Sponsors, and Targets) are also Champions.

> Project teams should recognize early on the importance of building the network of Agents and ensure these individuals have the skills and knowledge to be successful in this important role. After all, it's not the Champions that will have implementation responsibilities-- it's the Agents.

In a nutshell: Many people in many roles will be affected by and instrumental in the change you’re promoting. It’s important to tend to their needs throughout the change journey.

Read more…

Saturday, March 21, 2020

Case Study 11: How BBSI Blew Millions on an Oracle Cloud Solution

Case Study 11: How BBSI Blew Millions on an Oracle Cloud Solution
Oracle and its partners KBACE Technologies and Cognizant were sued in January 2019 by Barrett Business Services, Inc. (“BBSI”)  in San Francisco Superior Court, for fraud, negligent misrepresentation and breach of contract arising out of one of Oracle’s Cloud Service offerings.

BBSI (NASDAQ: BBSI) is a so-called professional employer organization ("PEO") in the business of establishing "co-employment" relationships with small and medium-sized companies. It assumes responsibility for their payroll, payroll taxes, workers' compensation coverage, employee benefits and other human resources functions. The clients retain responsibility for day-to-day operations and employee management.

BBSI bills its PEO services as a percentage of client payroll at the end of each payroll processing cycle. The gross amount, including direct payroll costs, employer payroll related taxes, workers' compensation coverage (if provided) and a service fee, is invoiced.

In 2017 BBSI supported in excess of 5,600 PEO clients with approximately 110,000 worksite employees located in twenty-four states through a network of sixty branch locations in different states of the US.

In 2019 BBSI had net revenues of $942.3 million and gross billings of $5.97 billion.

Before we continue with this case study...

> For an overview of all case studies I have written please click here.

> To subscribe to new Project Failure Case Studies just click here.

> To download all my Project Failure Case Studies in a single eBook for only $4.99 just click here or on the image.

Timeline of Events

According to BBSI it all went down like this.

Early 2017

BBSI utilized a combination of commercial and custom applications to manage its human resources, payroll and financial functions. BBSI believed that its legacy systems needed upgrading to improve scalability and stability, decrease reliance on manual 5processes, streamline its operations, increase efficiency and ensure that its user experience keep pace with its business objectives.

Thus, BBSI made the decision to upgrade to an Enterprise Resource Planning ["ERP"I Systems Integration Service. Galen Weaver ("Weaver"), BBSI's Director of Information Technology, undertook this task.

To this end, Weaver prepared a comprehensive and highly specialized list of human resources and payroll requirements mandated by BBSI's operations. Unlike other companies, BBSI did not have one payroll, with one tax identification number. Instead, it handled thousands of payrolls for thousands of employees in multiple companies across different states with varying state payroll tax requirements. Importantly, unlike most other companies, these payrolls were also BBSI's mechanism for generating revenue.

Among other things, BBSI's list of key functionality requirements included but were not limited to:

> Application Program Interfaces ("API") that would allow seamless integrations with its other key business systems for importing benefits, time and labor, absence and payroll data on a daily basis (like TimeNet, TimeClock and Bullhorn, Swipe, Busy Busy, etc);

> Ability to calculate certified payroll;

> Ability to file local taxes under BBSI's Employer Identification Number ("EIN") and not the customer's state EIN;

> A time entry grid-style screen with a customizable lay-out that shows all customer employees;

> A user interface for customers with a single uniform log-in point;

> A single screen that brings together all the various items that have to be created or managed for the clients;

> Ability to show multiple work relationships for employee self-service;

> Ability to allow clients to process payroll through a simplified professional user screen;

> Ability to enter time as a grid for a specific client's department, division, worksite location or project;

> Ability to include both positive and negative wages, deductions, hours within an employee's timesheet entry and many other requirements.

Weaver distributed this requirements list to several companies to determine if they had a compatible product, service or solution and interviewed thirty of the industry leaders in software technology.

June 2017

Among the several companies interviewed by Weaver was Oracle. Weaver conveyed BBSI's list of specific requirements to Oracle and on June 30, 2017, participated in a conference call with an Applications Sales Manager and a HCM Applications Sales Manager from Oracle.

After Weaver went over the requirements list and sought to carefully explain the uniqueness and complexity of BBSI's situation and unique needs as a PEO, the Oracle team represented to Weaver that their HCM Cloud system could and would be the best fit to provide BBSI with an integrated human resources and payroll system that would ensure satisfaction of its requirements. Oracle never presented BBSI with any other options.

July 2017

Because of these representations, BBSI invited Oracle to present an onsite demonstration on July 20, 2017 at BBSI's offices in Vancouver, Washington.

During that demonstration, Oracle informed BBSI that Oracle would have to be implemented by KBACE, Oracle's No.1 HCM Cloud implementer. KBACE is part of Cognizant, the 15 Billion IT service provider giant.

Oracle represented to BBSI that KBACE was a consulting and technology services company that specialized in cloud strategy, implementation and integration, which was certified and experienced in Oracle's HCM Cloud product implementation.

Oracle told BBSI that KBACE could successfully implement the HCM Cloud to fulfill all of BBSI's complicated human resource and payroll requirements.

August 2017

August 3, 2017 there was a conference call attended by Weaver of BBSI; several representatives from Oracle and several KBACE representatives.

Oracle and KBACE again told BBSI that KBACE was Oracle's No.1 HCM Cloud implementer, that KBACE had done in excess of 300 HCM Cloud implementations, had knowledge of the special requirements of PEOs like BBSI and was, in fact, currently deploying a PEO implementation for another company. Oracle never mentioned or recommended any other implementer.

Because of Oracle's and KBACE's representations, BBSI began considering the HCM Cloud product in earnest. BBSI had several hours-long in-person meetings and telephonic conferences with Oracle and KBACE.

At each of these meetings, BBSI took great pains to educate Oracle and KBACE as to the precise nature of its business operations, its peculiar needs and the business functions that informed BBSI's extensive list of requirements.

In meticulously discussing its list of requirements with both Oracle and KBACE, BBSI underscored its need for ease and efficiency of user interface and processes relating to payroll, time entry, billing and taxes given its human resource and payroll management challenges and the fact that payroll was also its revenue source. At all of BBSI's discussions with Oracle and KBACE, BBSI's list of requirements remained unchanged.

At all of BBSI's discussions with Oracle and KBACE, BBSI's representatives also made clear that they were ignorant as to Oracle's HCM Cloud system or any other Oracle products or how they performed and were relying wholly on Oracle and KBACE to advise them as to the suitability and capabilities of the product or system vis-å-vis BBSI's requirements.

The Oracle and KBACE representatives assured BBSI that Oracle's HCM Cloud system could handle BBSI's PEO requirements, which would be implemented by KBACE quickly and efficiently.

September 2017

On September 6, 2017, Oracle and KBACE were at BBSI headquarters to do an Oracle Cloud Roadmap Presentation. Multiple Oracle, KBACE and BBSI representatives were in attendance. During the presentation KBACE affirmed that they could configure Oracle's HCM Cloud to comply with BBSI's human resources and payroll requirements.

At the same meeting, KBACE also claimed extensive knowledge of payroll systems, and an understanding of the complexity of BBSI's PEO payroll needs.

December 2017

Finally, on December 5, 2017, after seven months of performing what BBSI
believed was Oracle and KBACE's due diligence, and with Oracle's apparent knowledge, involvement and consent, KBACE presented BBSI with a HCM Cloud implementation package according to BBSI's requirements at an estimated cost range of $5,410,000 to $5,950,000.

KBACE's "project overview" slide reflected an Accounts Payable/General Ledger ("AP/GL") "go live" date of July 29, 2018 and a "pilot population" and Accounts Receivable/Platform as a Service ("AR/PAAS") "go live" date of January 7, 2019.

What Went Wrong

Missing key functionalities

According to BBSI, soon after the implementation process was underway, KBACE began identifying significant and critical gaps in the functionality of the HCM Cloud product relative to BBSI's expressed requirements which were not previously disclosed to BBSI.

The HCM Cloud, among many other failings:

> Did not have sufficient APIs to allow for seamless 8integrations with BBSI's other key business systems;

> Required custom reports to be created to calculate certified payroll;

> Did not have the ability to file local taxes under BBSI's EIN;

> Did not have a grid-style screen for rapid time entry by either the customer or BBSI;

> Did not have a user interface for customers with a single uniform log-in point;

> Did not have a single screen that brings together all the various items that have to be created or managed for the clients;

> Did not have the ability to manage shared employees;

> Did not allow clients to process payroll through a simplified professional user screen;

> Did not have the ability to enter time as a grid for a specific client's department, division, worksite location or project;

> Did not have the ability to include both positive and negative wages, deductions, hours within an employee's timesheet entry; and

> Did not include Oracle's Time and Labor application thereby precluding BBSI from performing necessary automated record keeping of worker time and attendance.

BBSI received no notice of the existence or extent of these deficiencies prior to contracting.

BBSI had been under the impression that in recommending the HCM Cloud to BBSI and in the seven months before providing BBSI with implementation cost and duration assessments, Oracle and KBACE had conducted the necessary due diligence on the suitability, capabilities, functionalities, vulnerabilities and amount of customization necessary for the HCM Cloud system to comply with BBSI's architecture and requirements.

Because these critical gaps in functionality were "showstoppers" meetings were convened to address these issues.

At a June 5, 2018 at a face to face meeting, somebody from KBACE/Cognizant advised BBSI representatives that the Oracle HCM Cloud system was not the right system for BBSI's business functions and that BBSI should never have bought the system.

To BBSI's shock and dismay, this is the first time that BBSI heard any suggestion that the HCM Cloud system was not the right system for BBSI's functions or that they never should have bought the system.

No experience with PEO

At the same June 5, 2018 meeting, KBACE admitted that in fact, their only experience with a PEO implementation took place eleven years prior and did not involve the HCM Cloud.

Further, they admitted that KBACE lacked the expertise and ability to propose a solution that would meet BBSI's needs and indicated they would have to draw on Cognizant, its parent company's resources to devise a plan of action.

Expensive implementation services

On June 13, 2018, Oracle advised BBSI that unless BBSI changed the way it processed payroll, the HCM Cloud system would never perform to BBSI's current level or be able to process as fast as BBSI did before the HCM system was in place and that BBSI would need to schedule payroll by pay groups.

Thereafter, on June 25, 2018, KBACE/Cognizant purported to present BBSI with a revised proposal to provide implementation services and address the gap functionalities it had identified.

The new proposal withdrew the original implementation price quote of $5,410,000 and instead presented a new "Labor Total" of $33,059,274, almost six times greater than the original quote.

Extended go-live dates

In addition, KBACE/Cognizant's new proposal extended the original go-live dates. The new proposal now reflected:

> Completion of Phase I (i.e. Core Human Resources/BBSI Corporate, Financials, Legacy Accounts Receivable and Procurement) by April 15, 2019 instead of the original July 29, 2018

> Completion of Phase 2 (i.e. Core Human Resources, Financials, Accounts Receivable, Payroll, Absence Management, OTAC, Taleo and PaaS Extension Development for SaaS) by May 10, 2021 instead of January 9, 2019.

"Bait and switch"

Even with this price and time jump, however, the new proposal still offered no workable solutions to BBSI's satisfaction.

By email to Oracle dated November 14, 2018, BBSI's Chief Financial Officer, protested Oracle and KBACE's apparent "bait and switch" tactic. He noted that "[y]ou quoted BBSI a cost of $5.4M to implement and then when you were done with Accelerate, the quote was now $33M and would take twice as long." Because of the critical functionality gaps in the HCM Cloud solution that were never disclosed to BBSI before contracting and which neither Oracle nor KBACE could cure within the price and time quoted, Kramer advised Oracle and KBACE that BBSI would make no further payments for a system they did not and could not use and was rescinding the contracts.


BBSI alleges to have suffered economic harm in a myriad of ways. BBSI was forced to pay sums to Oracle and KBACE for which it received no value and also as a consequence of payments to third parties, including but not limited to, the following:

> $171,920 paid to the independent consultant
> $266,306 paid to KBACE for their useless services.
> $1,008,586 paid to Oracle for their useless products and services.

February 2018, BBSI employees began devoting significant resources to the implementation of the Oracle system. For instance, BBSI dedicated a seven person "project core team" working full time on the Oracle implementation. The project core team devoted over 9,000 hours to this project.

Further, there were 58 BBSI employees who devoted time to "project read-in." Some employees doing "read in" devoted as much as 29 hours per week to this work. These employees devoted over 1,800 hours to the project.

In addition, from March 2018 to present, there have been  BBSI employees working as "backfill" on the project. These employees worked over 2,000 hours. The cost to BBSI in terms of hours worked by its employees on this project exceeded $900,000.

If these BBSI employees had instead been working on revenue-generating ventures, these employees would have generated in excess of $3,000,000 in revenue, the exact amounts to be ascertained at trial.

Additionally, BBSI has lost time and opportunities with respect to system upgrades as well as incurred other damages, the exact amounts to be ascertained at trial.

How BBSI Could Have Done Things Differently

Independent third party assessments

Because of the many difficulties encountered during the HCM Cloud implementation, and the admissions by Oracle and KBACE representatives regarding the true limitations of the system and of KBACE, and the astronomical leap in the implementation cost range and duration, BBSI began talks with other consulting companies regarding the HCM Cloud.

These companies expressed shock that the HCM Cloud solution was recommended for BBSI and voiced concerns that, based on their knowledge and expertise, the HCM Cloud was not the right product for BBSI.

BBSI then hired an independent consultant to undertake a full review and assessment of the suitability of Oracle's HCM Cloud for BBSI's stated requirements. The independent consultant reported that the HCM Cloud was ill-suited to BBSI's requirements for several reasons.

BBSI could have saved a lot of headaches by hiring this independent consultant before signing a contract and spending serious amounts of money and effort.

Consider your industry-specific needs and solutions

PEO is a fairly unique industry. Standard Cloud HCM systems are less likely to address the variety of distinctive needs of companies in this space.

Be skeptical of concepts like SAP’s Model Company, Oracle’s Unified Model, NetSuite’s Suite Success and other software industry hoaxes that may mislead you to unrealistic expectations.

Industry best practices baked into software don’t exist. Neither do silver bullet implementation solutions. It is important to plan and execute accordingly.

Be a responsible buyer of technology

Being a responsible buyer of technology and implementation services, and working well with suppliers during projects are crucial skills for any organization.

Yet, the absence of those skills explains more project failures in third-party projects than any other factor. You will find some prominent examples of these among these and other project failure case studies.

Some may argue that suppliers should have all the skills required to make their projects a success, but any company relying completely on the skills of a supplier is making themselves dependent on good luck.

If you are not a ‘responsible buyer’ then you risk not spotting when the supplier and/or the product is failing. Things will always start to drift and get off track. That’s a normal part of complex cloud projects like these.

But the key is how we identify risks, mitigate risks, and take action when warranted.

Ask for reference clients to call

BBSI could have asked Oracle for a reference client to call. Ideally of course another PEO. These ten questions are a good starting point any software reference call:

1) How long have you been using the software?

2) Describe the process for getting up and running in the software. How long did it take, how much time and investment was required of you and your team, and did your experience match what the vendor had promised?

3) What are the top three things you use the software for today? Have the product features lived up to your expectations?

4) Have you identified any feature gaps or shortcomings in the product? If so, how has the vendor handled your feature requests? Is the solution updated frequently?

5) How would you describe the business value the software delivers to your organization?

6) How would you rate the customer service you receive from the vendor? How would you rate the quality and caliber of employees you interact with at the vendor? Do they know and understand your business?

7) If there are parties outside of your company who interact with the software (e.g., investors, partners, advisors), how has it been received? Have you received compliments or complaints?

8) What other products did you look at before deciding on vendor [x]? Why did you choose vendor [x] over the others?

9) Is there anything else about your experience with the software or vendor that you think I should know?

10) Can you recommend the vendor without reservation?

Closing Thoughts

As with any dispute, there are at least two sides to every story. There are many questions that will need to be answered to understand what really happened, but no matter what the answers are, BBSI did not act as a responsible buyer.

You can never just trust a vendor alone when it comes to fulfilling requirements. You have to put in some work to validate this.

You can delegate authority to the supplier but you cannot delegate responsibility.

In a nutshell: Responsibility for the project — including responsibility for it failing — always rests ultimately with the buyer.

Other Project Failure Case Studies

> For an overview of all case studies I have written please click here.

> To subscribe to new Project Failure Case Studies just click here.

> To download all my Project Failure Case Studies in a single eBook for only $4.99 just click here or on the image.



Read more…

Saturday, March 14, 2020

How to Talk About Technology With Senior Executives

Talking About Technology With Senior Executives
One of the biggest hurdles that keeps senior executives from getting closer to technology is the complexity of today’s IT environments, further obscured by the endless stream of buzzwords, jargon, and product names.

Working with executives over the last 15 years I realized that we can make it much easier for executives to “speak technology” if we split it’s “language” into two parts: grammar and vocabulary.

Grammar: A language’s grammar defines the structure and rules for composition of words into meaningful sentences. Similarly, the grammar of technology is the set of architecture rules and constraints that define how systems and components can be combined.

Vocabulary: This is the long list of (buzz)words and technologies that we use, often wrapped in jargon and fuzzy marketing terms.

Executives are largely put off by technology’s seemingly endless, unnecessarily cryptic, and ever changing vocabulary.

In contrast, it’s grammar, the rules that define how technology operates and makes decisions, is relatively static, and much more approachable to executives.

So to establish decision transparency you should leave buzzwords and products aside and instead focus on the available option space, the inherent trade-offs between the available choices, and the principles that guide these decisions.

Senior executives can much more easily grasp technology concepts and be involved in decision making once you remove the fog of jargon.

They are used to making decisions affecting their organizations, so the “grammar” of our world is actually quite familiar to them. This often comes as a surprise to both sides that always assumed that executives “aren’t technical”.

Presenting technology decisions in a way that emphasizes constraints and trade-offs without falling into buzzwords and jargon is incredibly difficult, but actually very helpful for IT teams and CIOs.

Things may be complex, but nothing is ever confusing in and of itself.

If something is confusing, that’s because you made it so.

In a nutshell: To established decision transparency you should leave buzzwords and products aside and instead focus on the available option space.

Read more…

Sunday, March 08, 2020

Raising Expectations and Performance

Raising Expectations and Performance
We always compare performance on a relative basis. “Well, it’s better than it was last month…”

My toddler son, for example, seems like a freaking genius compared to the baby he used to be.

Some people around us have embraced a strategy of always lowering expectations so that mediocre effort is seen as acceptable.

Over time, we embrace the pretty good memo, the so-so presentation, or the decent leadership moment, because it’s so much better than we feared.

And some? Some relentlessly raise expectations, establishing a standard that it’s hard to imagine exceeding.

And then people do.

If you are working with, or lead by someone in the first group, an intervention can be rewarding. For you and for the person trapped in this downward cycle.

Raising our expectations is a fine way to raise performance as well.

And no, working more hours is not the same as raising performance, just as working fewer hours is not the same as dropping performance.

It is about the quality, efficiency, and effectiveness of hours worked. Not quantity.

And in the case individual performance is actually dropping, the plentitude of reasons can be split into three buckets;

1) Personal issues (family, health, etc)

2) Engagement issues (engagement to the vision, interest in work, leadership, politics)

3) Skill issues (does not have the right skills to do the job)

The first bucket needs support, the second bucket needs re-alignment, the third bucket needs training or replacing.

If you see someone’s performance dropping address it immediately.

Have hard conversations first.

Never underestimate how much one individual's performance will impact team performance.

In a nutshell: Raise expectations and address individual performance problems immediately.

Read more…

Saturday, February 29, 2020

More Leadership. Less Management.

More Leadership. Less Management.
Why do so many projects continue to fail? An important aspect is the increased complexity of projects and the environments in which they are undertaken.

Many factors contribute to this growing complexity – social and technological change, growing global interdependence, increasing numbers of stakeholders and the need to communicate and coordinate cross-culturally.

Traditionally, a good project manager was someone who was logical and rational and effective at dealing with events, tasks and processes. It was someone who would work to the client’s brief and use his or her authority to deliver the desired outputs.

Often, this type of project manager would study best practices and company procedures so that the individual could play by the rules and ensure that the standards were upheld.

But this approach no longer works.

Or as one executive put it.

"If a project manager just follows orders he is not much use to me."

Building high-performing teams, creating great relationships and ensuring that the project actually delivers what the customer needs cannot be achieved solely through logic.

It requires creativity, empathy, risk-taking, vision and, most important, the ability to connect with people at a very personal level.

It requires leadership.

Managers work to get their employees to do what they did yesterday, but a little faster and a little cheaper.

Leaders, on the other hand, know where they’d like to go, but understand that they can’t get there without their team, without giving those they lead the tools to make something happen.

Managers want authority. Leaders take responsibility.

We need both. But we have to be careful not to confuse them.

Leadership is not attained through a job title but through a continuous journey of introspection, observation and development.

In a nutshell: We need more leadership and less management.

Read more…

Sunday, February 23, 2020

Projects Fail at the Beginning. And This is Why.

Projects Fail at the Beginning. Not at the End.
Beginnings are always difficult.

Projects are about people, people are about relationships, relationships are about trust, trust comes over time.

So at the very moment your project is at its most vulnerable because you don’t have enough information, credible plans, nor stakeholder support, you also don’t have the relationships with key people to fall back on.

The only way to start is to trust your instincts.

Something they won’t tell you in any project management methodology book.

It’s also not just what you do at the beginning of the project; it’s how you do it.

The ‘what’ is no huge mystery. Perfectly straightforward project management theory.

Go and buy any project management book for a list of all the things you need to get done at the beginning of a project; it’s no more complicated than the shopping list for a cooking recipe.

But what none of them will tell you is ‘how’.

The reason those books won’t tell is simply that there is no magic formula.

There is no list of successful habits to kick-start a project that works in the real world.

You aren’t going to learn it from any textbook because it’s all about people and relationships.

And that is one reason why so many projects fail at the beginning.

A project management certificate does not help anybody with their people and relationship skills.

Also what works for one project or company will not work for another.

You need to be able to read people, relationships, situations, and organizations,

You need to be able to trust your instincts.

In a nutshell: The only way to start a project is to trust your instincts because it’s all about people and relationships.

Read more…

Sunday, February 16, 2020

Project Success is a Self-Fulfilling Prophecy

Project success is a self-fulfilling prophecy.

Go around admitting doubt, and your project will fail.

Tell everyone that it will succeed and they will believe it too, and you have every chance of getting there.

You’re thinking it cannot be that simple?

That it just sounds like self-help psycho-babble?

All I can say is that I have never once in my life have seen a doubting project manager succeed.

The opposite is of course not necessarily true.

Believing in project success is necessary.

Believing alone is not sufficient to get the job done.

In a nutshell: Go around admitting doubt, and your project will fail.

Read more…

Sunday, February 09, 2020

Project ≠ Product ≠ Business ≠ Company

Project ≠ Product ≠ Business ≠ Company
Last few weeks I had a number of heated discussions around these terms. People get confused and make wrong decisions because of this.

This is my take on it.

A project is a temporary endeavor undertaken to create a unique product, service or result. It is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources.

And a project is unique in that it is not a routine job, but a specific set of jobs designed to accomplish a singular goal. So a project team often includes people who don’t usually work together – sometimes from different organizations and across multiple geographies.

Where each project is unique, doing projects is something that is recurring. Most organizations spend a lot of time and money on projects.

That is why investing in project management capabilities gives you usually a high ROI.

A product is something that you can build and sell, directly or indirectly. It is the "thing" (though it can be a service) that you could make money from via a business. By itself, though, it won't make money.

Typically the first version of a new product or service is the result of a project. The second version is usually not.

A business is a set of people, processes, and tools that have been structured around a product or service to enable it to make money.

Ideally, a business is profitable, but it may not be.

Ideally, a business doesn't depend on any specific person being a part of it (including the founders), but it may rely on some exceptional people.

You can't run a business solely with projects. You need day-to-day operations.

A company is an organization of people that is designed to run one or more businesses successfully and to create new businesses to respond to opportunities in the marketplace.

This must be, ultimately, independent of any specific employee, since companies, unlike products and businesses, are (or should be) built to last for decades.

A business is worth much more than the product that it sells.

A company is worth much more than the business that keeps it alive.

This is one good rationale for why some startups (e.g. WeWork, Facebook, Twitter), operating in environments where it's easy to raise money, have bypassed the "build a business" step to go straight to building a company.

The danger with that is that if you don't first build a business, you might end up building a company that's incapable of building new businesses - and that's not worth a whole lot.

In a nutshell: Project ≠ Product ≠ Business ≠ Company

Read more…

Monday, February 03, 2020

Leadership Is Not for Cowards

Leadership Is Not for Cowards
Fewer “bad leader” types have the capacity to paralyze a team more than a coward – the leader who praises poor performance, avoids difficult issues, and buys loyalty by saying yes to anyone and any idea.

The dictionary defines the word coward, when used as a noun, as “a person who lacks courage in facing danger, difficulty, opposition, pain, etc.; a timid or easily intimidated person.

Coward leaders are in every organization, at every level of an organization, from the first line supervisor to the company CEO; government bureaucrats to elected officials ... they’re out there ... they’re everywhere … like an insidious disease; they corrupt employee morale, destroy trust in teams and organizations, and even threaten the very existence of their teams and organizations.

Working for one is probably one of the most discouraging experiences one can have.

Below are thirteen differences between strong leaders and cowardly ones. Recognize any of these characteristics in your own manager -- or yourself?

1) Strong leaders reward achievement rather than effort

Weak leaders, on the other hand, reward effort rather than achievement. It’s a mistake to be too “soft” about expectations, to say, “Just do your best.” People will not achieve just because you encourage and motivate them. Somebody must drive performance. Somebody must plant the flag on the hill and refuse to accept anything but success. That somebody is you.

Courageous leaders layout expected results in the most effective and humane way possible and are clear about the consequences of not meeting them. Managers may worry about upsetting their employees, so they don’t set high expectations.

I believe in a respectful workplace where people enjoy their jobs and look forward to coming to work, but I am also in full support of less whining and more doing, less passing the buck and more personal responsibility, less explaining why you didn’t and more showing how you did.

2) Strong leaders collaborate with their team members to create a vision

Cowardly leaders don't dare to establish a vision -- they take their orders from the higher-ups. It takes courage to have vision, because you have to believe you can realize the vision, no matter what obstacles may appear in your way.

Cowardly leaders are more comfortable measuring people against handed-down yardsticks, than inspiring people to achieve great things.

3) Strong leaders hire strong and confident people

They don't hire people based on endless lists of essential requirements but rather based on the pluck and brains of the candidates they meet. Cowardly leaders stick like glue to the bulleted list of essential requirements when they hire people. All they need to know is "Is this person a 'safe' hire that I won't be criticized for hiring?" and "Is this person someone who will listen to me?"

Cowardly leaders don't dare hire someone with their own ideas, because that person might outshine the manager one day!

4) Strong leaders tell the truth about sticky topics

If they run into a conflict with an employee, they'll address it head-on and compassionately. They'll say, "Look, we see things differently regarding the project scope and priorities. Let's talk about it."

Cowardly managers don't dig into conflict in order to sort it out. They say, "I'm the manager, so we're going to do it my way.", or they don't say anything at all. That way they don't have to look any more closely at their words and actions than they're comfortable with.

5) Strong leaders speak up when they feel strongly about something 

If a new policy gets enacted at Corporate and they're told they must enforce the new policy, strong leaders will go to their boss and say "Red alert! This policy makes no sense. It will anger our employees and suck away our team's precious mojo." When six or eight supervisors all say the same thing with equal vehemence, the manager will tell the folks at Corporate that the new policy is %&ç@ and the Corporate people will revisit it.

A cowardly supervisor may hate the new policy as much as a strong supervisor does, but they won't speak up. They'll enforce the policy and tell their employees, "There's nothing I can do about it."

6) Strong leaders take responsibility instead of placing blame

This is an energy-draining, counterproductive way of dealing with difficult circumstances. Blaming someone else puts you in the position of a victim who is not in control. Therefore, you won’t take action to change your circumstances because it’s someone else’s problem. (How convenient, huh?). Victim thinking affects not just individuals but entire organizations.

Acknowledging that you are ultimately responsible for the results of your life, thoughts, and actions creates a level of freedom not experienced by those who choose to blame others. It empowers you to act. Courageous leaders are driven by, even obsessed with, the imperative to eliminate excuse-making and blame from themselves and their organizations.

7) Strong leaders give people latitude

They are available to answer questions, but their general posture is "It's your job -- do it your way." Weak leaders don't trust themselves enough to hire people they can trust. They spell out every detail -- and woe to the employee who does their job even slightly different from the standard process. They are like a helicopter.

Helicopter leaders are afraid to let go because they believe the work won’t get done if they don’t oversee every detail. Either this fear is unfounded or it’s a sign that employees really aren’t capable of doing their jobs. The solution is simple: do your job and let them do theirs, or get rid of incompetent employees and replace them with people who can get the job done.

8) Strong leaders know they don't know everything

They lead through trust, rather than fear. If a teammate tells the supervisor, "I think you're using the A valve, but it's the B valve we need," the supervisor will say, "Thanks for noticing that!" They don't freak out when somebody corrects them, because they know that it takes everybody's brain cells to make a department go.

Cowardly managers can't stand being corrected. They don't want to learn from their teammates. They aren't open to learning in general!

9) Strong leaders take the easy way out only if it is the right way

Weak leaders frequently take the easy way out. They avoid taking bold, decisive action because it makes them uncomfortable. Then, they rationalize why they didn’t do what they really needed to do. It’s easier to avoid taking action (at least in the short term), but it’s also a sure path to mediocrity and stagnation.

10) Strong leaders don’t pretend to don’t know what they know

Weak leaders pretend they don’t know what they actually know. They pretend they don’t know about opportunities in order to avoid risk. They pretend they don’t know that a high performer is behaving badly and making other employees unhappy. They pretend that your biggest client isn’t crushing employee morale. Maybe, they even pretend they don’t know it’s time for them to move on.

All of this pretending allows them to avoid pain and feel good in the short term, but it exacts a heavy price over time. There is always a price to be paid for necessary actions not taken. The job of a leader is to look reality in the face and accept it so that you can make the tough decisions that need to be made.

11) Strong leaders don’t ignore what’s causing “weight and drag” in their organization

Maybe it’s a policy, a person, or a mindset that’s holding them or their team back from optimal performance. They ask themself: What am I doing, or not doing, that is adding weight and drag? Am I refusing to make a decision, waiting to hire an assistant, delaying a hiring or firing issue?

At the core of your job as a leader is your role as an obstacle remover. Be courageous: remove the obstacles you can and work around the ones that remain so that you can stay productive, directed, and focused.

12) Strong leaders don’t hide behind the “I’m not quite ready” excuse

Leaders and organizations spend too much time getting ready to be ready to get ready to almost get ready to be ready to get ready. Then they form a committee or a task force (which is just a committee on steroids) to evaluate more and look into the situation more so that they can really be ready. Getting overly ready is a result of fear. You don’t want to fail so instead you put off the moment of truth by perpetually getting ready.

Should you prepare? Of course! Do your research? Yes. But stop hiding behind the “we aren’t quite ready” curtain. Say, “Enough is enough,” and just do it—even if conditions aren’t perfect.

13) Strong leaders don’t ignore information

Weak leaders see only the information that agrees with their beliefs. We all have a natural tendency to ignore information that contradicts our beliefs about the world, especially our negative beliefs. If we believe someone doesn’t like us, we will see only those behaviors that support that impression. If we think we are bad at something, we will see only more evidence of that conclusion. This tendency is so strong that it blinds us to contrary evidence. As long as we don’t see other possibilities we don’t have to take action.

Closing thoughts

The business world is full of coward leaders; as is the government. Of all the factors that are used to describe a coward leader the one element of the coward leader that usually isn’t mentioned is the basic character flaw of not having the guts to look you in the eye and being honest with you. They will try to find any way they can to avoid dealing with tough issues. Coward leaders are scared people, refusing to confront at all costs… Don’t be one of them.

In a nutshell: Leadership is not for cowards.

Read more…

Friday, January 31, 2020

Case Study 10: LeasePlan Paid $100 Million for a SAP System That Never Went Live

Case Study 10: Leaseplan Paid $100 Million for a SAP System That Never Went Live
International automotive fleet management company LeasePlan has been hit by a massive bill for a failed SAP implementation. LeasePlan has since dropped SAP to pursue an alternative IT infrastructure, citing the “monolithic nature” of the ERP system as being incompatible with its more agile needs – but not before sinking almost €100 million into its SAP efforts.

Established in the mid-1960s, LeasePlan is one of the world’s leading fleet management and driver mobility companies, with 1.8 million vehicles under management in more than 30 countries, and approximately 6,600 employees. Their core business involves managing the entire vehicle life-cycle for their clients, taking care of everything from purchasing and maintenance to car remarketing.

Before we continue with this case study...

> For an overview of all case studies I have written please click here.

> To subscribe to new Project Failure Case Studies just click here.

> To download all my Project Failure Case Studies in a single eBook for only $4.99 just click here or on the image.

Timeline of Events


At this point of time LeasePlan has offices across 32 countries and is owned by a consortium consisting of the Volkswagen Group (50%), Olayan Group (25%), and Mubadala Development Company (25%).

Each location operates under the same brand, but each country uses its own model to do so.

Alfonzo Venturi, CIO for LeasePlan Australia, explained that every country was basically allowed to do its own thing; run its own IT, and manage its own activities.

"Yes, we all reported up, but we had autonomy to really do what we wanted to. If you can imagine 32 entities with 35 leasing solutions -- so very expensive, with no agility at all," he explained. "Any change would take a long time and it just wouldn't allow us to do any of the new technology sharing that our customers are wanting today."


In 2016, LeasePlan, headquartered in the Netherlands, picked up a new 100 percent shareholder in LP Group BV, which represents a consortium that includes Dutch pension fund service provider PGGM, Denmark-based pension fund ATP, GIC, Luxinva SA, and investment funds managed by TDR Capital LLP.

"In all the due diligence prior to the acquisition, they saw that there was a major opportunity in IT," according to Venturi. "I think they started realising that something had to be done and they couldn't continue the way we were going."

This kicked off a large programme aimed at designing and building a Core Leasing System (CLS) based on SAP’s enterprise resource planning technology which was used at LeasePlan Australia since 2010. It was here the trouble began.

Venturi was asked to visit a number of European countries to perform a feasibility study and assess the possibility of putting the Australian-based solution in place.

He conducted a proof of concept for three LeasePlan entities, which Venturi said ticked all the boxes. Following the closing of the acquisition, the new owner wanted to see this stretch to the rest of the world.

Venturi then performed a full assessment of each country and it was decided he would lead the way with replacing the legacy systems in 15 countries in Europe -- as a first step -- taking the baseline of what he did in Australia and filling in the country-specific gaps.

India-based system integrator and SAP partner HCL Technologies has been brought in as a strategic partner.

SAP will provide a host of solutions to LeasePlan “to support our main operations end-to-end, achieve efficiency and straight-through processing”.

These are SAP Leasing at the back-end, Fiori for user experience (UX), Ariba for procurement, Hybris for e-commerce and product content management, S/4HANA (including for the new insurance business) and Business Objects for reporting and analytics/business intelligence (BI).

The deployment will be done on the Amazon Web Services (AWS) cloud. The Australian operations that already have SAP’s tech deployed on-premise on IBM’s servers will continue to operate as is for the time-being.

The first country to go live is planned to be the head office in the Netherlands, slated for October 2017.

This will be followed by the roll-out of a single instance of the system across 15 countries, mainly in Europe plus Australia (new SAP components, such as Hybris) and New Zealand.

This phase is set to be completed by October 2020. There will be two main deployment stages per year – in April and October. These will be “big bang” go-lives in the majority of countries, with a couple of exceptions where the operations are deemed too big. In these cases, go-lives will be phased by customer segment.

“We will go live with the minimal viable product, and expand functionality at a later stage,” Venturi says.

The remaining countries will follow at later stages as well.

All legacy systems will be switched off.


As the company’s new owners sought to drum up interest in shares ahead of a stock market launch, LeasePlan announced the plans to use SAP to streamline and smooth internal operations across all of LeasePlan’s country organisations, making the group more efficient and lowering total costs of ownership.

When LeasePlan subsequently launched its initial public offering in October 2018, the company repeatedly stated that it had high expectations of the benefits its new SAP system would bring.

This was supposed to be a chief reason for investors to factor in a considerable IT-driven efficiency in their valuation of the lease company. Not all investors however fell for the charm offensive, however.

LeasePlan found investors were unwilling to pay what its shareholders had set as a target, and in the same month it was announced, LeasePlan abruptly called off its initial public offering, blaming the deterioration in “market conditions”.


In the 12 months since the called off IPO, the worst possible scenario has unfolded for LeasePlan. In September 2019, the company finally pulled the plug on the major SAP project. A total investment of €98 million has been deemed unrecoverable and subsequently impaired from the firm’s books.

CEO Tex Gunning in a recent meeting with shareholders said, “The system is not fit for purpose in the emerging digital world. The monolithic nature of the SAP system hinders its ability to make incremental product and service improvements at a time of accelerated technological change. As a consequence, the system is being restructured.”

Instead, LeasePlan will now press forward with work on an alternative IT solution, which it has called a “Next Generation Digital Architecture”. Rather than placing its faith in one supplier from now on, the car leasing company is opting for a combination of best-of-breed third-party solutions combined with a deeper in-house involvement. The company will now leverage leading off-the-shelf solutions for various modules (e.g. contract management, insurance claims, predictive maintenance) and combine them with existing LeasePlan best practices to form its new infrastructure.

This approach is, according to Gunning, better suited to the “digital revolution” taking place in the global lease industry. It will allow for a more scalable and flexible IT infrastructure, smoother product deployments and updates, and will enhance integration with third-party systems to speed up innovation.

What Went Wrong

Since LeasePlan is a private company, and currently there is no public lawsuit going on, it is hard to find information about what actually went wrong.

But in conducting research for this case study, I found a number of warning signs that should have tipped off the company, its team, and its consultants that this was going to be a very difficult project.

Here are a few of the warning signs, which were found in articles with various quotes from LeasePlan executives touting the merits of the transformation:

> The company was consolidating 35 systems into one, which is typically a Herculean task in and of itself.

> The company failed in a past SAP implementation at one of its affiliates, which took 4 years to implement and another 3 years to “settle down” after go-live.

> The company’s CIO touted its “extremely aggressive plan” for rolling out the new technology, which is typically not a good thing.

> LeasePlan was pursuing a big bang rollout strategy for most countries it operated, which creates a high-risk profile for most organizations.

> The team acknowledged that change management would be difficult, but that they had it under control with a “comprehensive change management” plan.

How LeasePlan Could Have Done Things Differently

Consider your industry-specific needs and solutions

Fleet leasing is a fairly unique industry. Standard, off-the-shelf ERP systems are less likely to address the variety of distinctive needs of companies in this space.

You may also be in a similar industry. For example, digital transformations are typically more difficult for industries and companies such as these that are unique:

> Financial services
> Complex, engineer-to-order manufacturing
> Utilities and energy
> Any industry with field services
> Fast-changing industries
> Companies that are actively disrupting the status quo in their respective industries

Be skeptical of concepts like SAP’s Model Company, Oracle’s Unified Model, NetSuite’s Suite Success and other ERP software industry hoaxes that may mislead you to unrealistic expectations.

Industry best practices baked into software don’t exist. Neither do silver bullet implementation solutions. It is important to plan and execute accordingly.

If you fit into any of the categories above, it is less likely that a single-vendor solution is going to be the best fit for your strategic and operational needs. It is more likely that a best of breed approach with multiple technologies is going to be a more viable option.

Align technology with your business model

Digital transformations are too often misaligned with an evolving business model and overarching corporate strategy. It is nearly impossible to succeed in this type of situation.

Not only is LeasePlan in a unique industry, but it was also actively disrupting its industry with new platforms such as and its Car-as-a-Service business models.

This entrepreneurial spirit and new ways of doing business are typically not playing to the strengths of S/4HANA. This misalignment likely created problems during the transformation.

It is important that you understand your business model and define how your digital transformation or project will support that bigger-picture strategy. If you don’t see or don’t define the connection for the rest of your team, then you’re not ready to be starting a large-scale transformation.

Be a responsible buyer of technology

Being a responsible buyer of technology and outsourced software development services, and working well with suppliers during projects are crucial skills for any organization.

Yet, the absence of those skills explains more project failures in third-party projects than any other factor. You will find some prominent examples of these among these and other project failure case studies.

Some may argue that suppliers should have all the skills required to make their projects a success, but any company relying completely on the skills of a supplier is making themselves dependant on good luck.

If you are not a ‘responsible buyer’ then you risk not spotting when the supplier and/or the project is failing. Things will always start to drift and get off track. That’s a normal part of complex business transformations like these. But the key is how we identify risks, mitigate risks, and take action when warranted.

That could mean firing our systems integrator before we are $100M in the hole. It could mean that we pivot on our strategy when we see that the original plan isn’t working. Or it could mean that we divert resources from technical workstreams so we can double-down on our organizational change management strategy.

Closing Thoughts

A responsible buyer of third-party systems and systems development will have excellent knowledge, understanding and experience in defining, planning, directing, tracking, controlling and reporting systems development projects. They will know what should be done, when, why and how.

In many projects the supplier should be running the above-mentioned processes as part of helping a buyer achieve their target business outcome (after all, the supplier is expected to have done a great many projects of this type). However, this does not mean that the supplier will, in fact, be doing all of those things.

That's why it is vital that the buyer themselves knows what needs to be done.

In most large technology projects, it is excellence in program and project management that is the crucial factor in determining success — not knowledge of technology. This is often true in situations when, for example, a project is being carried out across an organization (especially a global organization); across a group of companies in collaboration; or on behalf of a central marketplace and its participants (such as a stock exchange).

In large business-critical projects neither the supplier nor the buyer should be doing any aspect of the project in isolation, as doing so will increase the risk of failure. This isn’t just a need for transparency, it is a need for active communication plus active confirmation and verification that messages have been received and understood.

The following three excuses for total project failure will never work in court:

1) "I was drunk,"
2) "I thought the buyer or supplier knew what they were doing," and
3) "I thought the buyer or supplier was doing it, not me."

If you are the buyer and you do not have all the necessary skills and experience to be able to define and control important projects (which is perfectly understandable as in most companies they don’t happen very often), there is an easy fix for this problem: Hire a very experienced interim executive to act on your behalf, even if the supplier will still do most of the project management and other work. You can delegate authority for doing the project management to the supplier but you cannot delegate responsibility.

Responsibility for the project — including responsibility for it failing — always rests ultimately with you, the buyer.

Other Project Failure Case Studies

> For an overview of all case studies I have written please click here.

> To subscribe to new Project Failure Case Studies just click here.

> To download all my Project Failure Case Studies in a single eBook for only $4.99 just click here or on the image.


> Article Financial Times

> Article ZDNet

> Article FinTech Futures

> Article Consultancy UK

> LeasePlan Q2 2019 Results

Read more…

Monday, January 27, 2020

What Makes a Good Project Manager?

What Makes a Good Project Manager?
Over the years I’ve noticed a key distinction for project managers that deliver results and the ones that don’t.

Project Manager Type A is a person who is very smart, knows the process, knows the business, knows the client, knows the technology, etc.

They do an excellent job of reporting on how things are going, writing up status documents.

Project Manager Type B does everything Type A does, but then they take the crucial extra step of doing something about the problems, of proactively seeing them coming, and working with the people in the project to fix it.

Put another way, I’ve had some project managers over the years tell me “the house is on fire,” and others tell me “we contained the fire to one room, and the fire trucks are on their way.”

Some project managers who come from large organizations with long, complex projects seem to be the worst form of type A.

They seem to think they are really good at project management - having come from such a prestigious company - and "managing" a large team and budget.

In reality, they are just really good at telling people "the house is on fire".

In a nutshell: good project managers take the crucial extra step of doing something about the problems instead of just reporting them.

Read more…

Monday, January 20, 2020

If You Want to Bring Change in Your Organization …

If You Want to Bring Change in Your Organization
People don’t change. Unless they want to.

Humans are unique in their ability to willingly change. We can change our attitude, our appearance, and our skillset.

But only when we want to.

The hard part, then, isn't the changing.

It’s the wanting.

So if you want to bring change in your organization you should make your people want it as well.

It's tempting to try to do this just one person at a time. After all, if you fail, no one will notice.

It's also tempting to try to change everyone at once. But of course, there really is no everyone. Too many different situations and narratives. When you try to change everyone, you're mostly giving up.

The third alternative is where real impact happens: Finding groups of people who want to change together.

Organizing them, and then teaching and leading them.

It's not only peer pressure. But that helps.

When a group is in sync, the change is reinforcing. When people can see how parts of your message resonate with their peers, they're more likely to reconsider them in a positive light. And mostly, as in all groups, "people like us do things like this" is the primary driver.

And some people just hate change.

They don't hate you.

If you get confused about that, it's going to be difficult to make (needed, positive, important) change.

In a nutshell: To bring change in your organization find groups of people that want to change together. 

Read more…

Monday, January 13, 2020

Designed by Clowns, Supervised by Monkeys (Or How to Work With Your Regulators)

How to Work With Your Regulators
Boeing expressed regret at the embarrassing communications it sent to investigators early January, which included a comment that “this airplane is designed by clowns, who are in turn supervised by monkeys.”

Employees of Boeing mocked federal rules, talked about deceiving regulators and joked about potential flaws in the 737 Max as it was being developed, according to over a hundred pages of internal messages delivered to congressional investigators.

“I still haven’t been forgiven by God for the covering up I did last year,” one of the employees said in messages from 2018, apparently in reference to interactions with the Federal Aviation Administration (FAA).

The most damaging messages included conversations among Boeing pilots and other employees about software issues and other problems with flight simulators for the 737 Max, a plane later involved in two accidents, in late 2018 and early 2019, that killed 346 people and threw the company into chaos.

The employees appear to discuss instances in which the company concealed such problems from the FAA. during the regulator’s certification of the simulators, which were used in the development of the Max, as well as in training for pilots who had not previously flown a 737.

“I just Jedi mind tricked this fools. I should be given $1,000 every time I take one of these calls. I save this company a sick amount of $$$$.”

“Would you put your family on a MAX simulator trained aircraft? I wouldn’t.”

“I’ll be shocked if the FAA passes this turd.”

“This is a joke. This airplane is ridiculous.”

“Best part is we are re-starting this whole thing with the 777X with the same supplier and have signed up to an even more aggressive schedule!”

“Jesus, it’s doomed.”

In an exchange from 2015, a Boeing employee said that a presentation the company gave to the FAA. was so complicated that, for the agency officials and even himself, “it was like dogs watching TV.”

Several employees seemed consumed with limiting training for airline crews to fly the plane, a significant victory for Boeing that would benefit the company financially. In the development of the Max, Boeing had promised to offer Southwest a discount of $1 million per plane if regulators required simulator training.

In an email from August 2016, a marketing employee at the company cheered the news that regulators had approved a short computer-based training for pilots who have flown the 737 NG, the predecessor to the Max, instead of requiring simulator training.

“You can be away from an NG for 30 years and still be able to jump into a MAX? LOVE IT!!” the employee says, following up later with an email noting: “This is a big part of the operating cost structure in our marketing decks.”

Last year, Boeing disclosed internal messages from 2016, in which a top pilot working on the plane told a colleague that he was experiencing trouble controlling the Max in a flight simulator and believed that he had misled the FAA.

“I basically lied to the regulators (unknowingly),” the pilot, Mark Forkner, said to his colleague, Patrik Gustavsson.

Boeing did not inform the FAA about the messages when the company first discovered them, waiting until about two weeks before Mr. Muilenburg was set to testify in front of Congress to send them to lawmakers. The conversation, which took place before the Max was approved to fly, angered key FAA officials, who felt misled by the company, according to three people familiar with the matter.

Representative Peter DeFazio, a Democrat from Oregon who is leading the House investigation into the development of the 737 Max, called the newly released messages “incredibly damning.”

“They paint a deeply disturbing picture of the lengths Boeing was apparently willing to go to in order to evade scrutiny from regulators, flight crews and the flying public,” he added, “even as its own employees were sounding alarms internally.”

Besides an appalling disrespect for human lives, Boeing shoes how not to build relationships with regulators.

Depending on how regulated your industry is, your company will have more or less contact with its regulators. You should think about your relationships with regulators in four categories:

1) Relationships in ordinary periods where no proposed regulation is being considered and no examination is underway,

2) Relationships when a rule is proposed or likely to be proposed by your regulator;

3) Relationships when you are being examined by your regulator, and

4) Relationships when your regulator is investigating your company or individuals associated with your company.

It is critical for the long term success of your company and the success of your regulator that you interact with your regulator in a constructive way in each of these circumstances.

During Ordinary Periods

The most important time to build a relationship with your regulator is when you have no current matters with your regulator.

For everyone in this technology-fueled age, we all feel like they are in fact no quiet times because it feels like there’s always too much work to do and not enough people to do it. But during the times when you are not engaged with the regulator about a rulemaking, examination or an investigation is the best time to develop your relationship with your regulator.

Your regulator may have access to a tremendous amount of data about your industry and that may lead you to think that your regulator is on top of developments in your industry and even with your company. The reality is that your regulator is a branch of the government. As such, your regulator is almost undoubtedly dealing with technology that is way behind the technology that you take for granted every day.

So when things are quiet I urge you to approach your regulator and offer your assistance. One very simple way to provide that assistance is to meet with the regulator and let them know what you are seeing in your industry. What business developments are driving innovation and change in your industry? What holdover practices from earlier times do you feel have not caught up with current operations? What risks do you see in your industry in the future?

These are topics that you are thinking about anyway in the course of managing your business and implementing sufficient compliance efforts for your business to comply with applicable rules and regulations. If you can convey your knowledge of these issues to your regulator, you’ll make your regulator better informed and better able to craft policies to address issues in your industry.

During a Rulemaking

When your regulator turns to action, like a proposed rulemaking that will impact your industry, you have another opportunity to build an effective relationship with your regulator. If you are already engaged with your regulator and communicating regularly you will have a distinct advantage in engaging on a rulemaking. If you are not already engaged with your regulator at that point, you should get engaged.

Rule proposals from the SEC for example often asked for data about particular issues and they often would not get any data from the industry. I know that there is an argument that says that industry is better off not sharing information with an SEC or another regulator. The idea behind this argument is that sharing information and data may lead the regulator to do something it wasn’t otherwise considering.

Just like in industry, the vast majority of regulators are trying to do the right thing with the information they have. If you give them more information, you have a better chance of them coming out with a rule that will be well thought out and supported by the data.

During an Examination

If your company is subject to an examination by the FINMA, SEC, RAB, BaFin or another regulator, you have another opportunity to build your relationship with your regulator.

I realize there are a number of my readers who might not have quite that reaction to an exam! I understand that an exam can be a tremendous expenditure of resources by your company and can be a source of concern that examiners may find something that you may have overlooked. Nonetheless, an examination involves a sustained interaction with your regulator.

It gives you an opportunity for the regulator to understand who you are and what your company is trying to do. Don’t waste this chance. If the examination does show an issue or a problem, you are far better off if you have been cooperative during the examination and explained your compliance efforts. If you have been uncooperative and hostile and the examiners find something, I promise you they will take a less charitable view of any explanation that you give.

During an Investigation

If all of your best efforts do not work out and you come under investigation from a regulator, are you past the point of maintaining a relationship with your regulator? While I hope that you don’t end up under investigation, I also would argue that all is not lost.

If you find yourself under investigation, I recommend that you maintain a spirit of cooperation and continue to explain the facts that landed you in the investigation. I have seen investigations being dropped because the company involved was able to adequately explain its conduct.

Enforcement departments of regulators like to win their cases as well. If you have an explanation for facts that may seem to be a problem, enforcement teams will listen. They would rather find out sooner rather than later. Don’t let your relationship with the regulator lapse just because you are under investigation. Keep up your effort to engage and to provide information that your regulator needs. You will have a better chance of the investigation being closed out without being charged.

In a nutshell: Develop and maintain relationships with your regulators for the long term success of your company.

Read more…

Tuesday, January 07, 2020

Tell the Story of Your Project

Tell the Story of Your Project
Persuasion is essential for a business and the projects that originate from this business.

Customers must be convinced to buy your company’s products or services, employees and colleagues to go along with a new strategic plan or reorganization, investors to buy (or not to sell) your stock, and partners to sign the next deal.

But despite the critical importance of persuasion, most executives struggle to communicate, let alone inspire. Too often, they get lost in the cesspool of company speak: PowerPoint slides, dry memos, and hyperbolic messages from the corporate communications department.

Even the most carefully researched and considered efforts are routinely greeted with cynicism, lassitude, or outright dismissal.

I firmly believe that you can engage listeners on a whole new level if you toss your PowerPoint slides and learn to tell good stories instead.

Stories have been implanted in you thousands of times since your mother took you on her knee. You’ve read good books, seen movies, attended plays. What’s more, human beings naturally want to work through stories. Cognitive psychologists describe how the human mind, in its attempt to understand and remember, assembles the bits and pieces of experience into a story, beginning with a personal desire, a life objective, and then portraying the struggle against the forces that block that desire.

Stories are how we remember; we tend to forget lists and bullet points.

If a story is “good” or “bad” is relative to the opinion of the listener. But there are a few non-negotiable components that make for a great story, for both the listener and teller.

Good stories are …

entertaining. Good stories keep the listener engaged and interested in what’s coming next.

educational. Good stories spark curiosity and add to the listener’s knowledge bank.

universal. Good stories are relatable to all listeners and tap into emotions and
experiences that most people undergo.

organized. Good stories follow a succinct organization that helps convey the core message and helps listeners absorb it.

memorable. Whether through inspiration, scandal, or humor, good stories stick in the listener’s mind.

There's no such thing as a true story. As soon as you start telling a story, making it relevant and interesting to me, hooking it into my worldviews and generating emotions and memories, it ceases to be true, at least if we define true as the whole truth, every possible fact, non-localized and regardless of culture.

Since you're going to tell a story, you might as well get good at it, focus on it and tell it in a way that you're proud of.

Storytelling is a skill. It’s not something you’re born with, it’s not based on charisma or authority. It’s more simple than you think, but it takes practice.

So tell the story of your project.

If you aren’t then someone else will be. And their version is likely to be worse than yours.

In a nutshell: You can engage listeners on a whole new level if you toss your PowerPoint slides and learn to tell good stories instead.

Read more…