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.

Read more…

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…

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…

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.

To download all my Project Failure Case Studies in a single eBook just click on the image.

Timeline of Events

2015

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."

2016

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.

2018

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”.

2019

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 CarNext.com 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 download all my Project Failure Case Studies in a single eBook just click on the image.

References

> Article Financial Times

> Article ZDNet

> Article FinTech Futures

> Article Consultancy UK

> LeasePlan Q2 2019 Results

Read more…

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…

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…

Designed by Clowns, Supervised by Monkeys (Or 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…

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…

How to Deal With Stakeholders Resistance to Change

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.

No matter the size or scale of the project, people resist change. Overcoming this resistance to change is a top challenge faced by organizations and project sponsors today.

The better we are at seeing what causes resistance, the easier it will be to build support for our ideas. In other words, if we understand resistance, we also understand the other side of that coin – support for change.

Rick Maurer identified in his book “Beyond The Wall Of Resistance” the three reasons for resistance.

1) I Don’t Get It
2) I Don’t Like It
3) I Don’t Like You

I Don’t Get It

This is about information: facts, figures, ideas. It is the world of thinking and rational action. It is the world of presentations, diagrams, and logical arguments.

Resistance may come from ...

> Lack of information
> Disagreement with data
> Lack of exposure to critical information
> Confusion over what it means

Many make the mistake of treating all resistance as if it is because of not understanding the change. Well-meaning leaders give people more information – hold more meetings, and make more PowerPoint presentations – when, in fact, something completely different is called for. For example...

I Don’t Like It

This is an emotional reaction to the change. Blood pressure rises, adrenaline flows, pulse increases. It is based on fear: People are afraid that this change will cause them to lose face, status, control – maybe even their jobs.

It is not soft stuff. You can’t say, “Just get over it,” and expect people to say, “Wow, thanks, I needed that.” It runs deep. When it kicks in, we can feel like our very survival is at stake.

When this kind of resistance is active, it makes communicating change very difficult. When adrenaline shoots through our system, we move into fight-or-flight mode (or we freeze like a deer in the headlights). And we stop listening. So no matter how terrific your presentation is, once people hear “downsizing” their minds (and bodies) go elsewhere. And this is uncontrollable. They are not choosing to ignore you, it’s just that they’ve got more important things on their minds – like their own survival.

Organizations usually don’t encourage people to respond emotionally, so employees limit their questions and comments to “I Don’t Get It” issues. They ask polite questions about budgets and timelines. So it may appear that they are with you, but they’re not. They are asking for more information while hoping that you’ll read between the lines and speak to their fears. And here is a really tricky part – they may not even be aware that they are operating on such a basic emotional level.

I Don’t Like You

So maybe they like you, but they don’t trust you – or don’t have confidence in your leadership. That’s a hard pill to swallow, I know. But lack of attention to this is a major reason why resistance flourishes and changes fail. And it is seldom talked about. Books on change talk about strategies and plans (all good stuff, to be sure) but most of this advice fail to recognize a major reason why change fails.

In this case, people are not resisting the idea – in fact, they may love the change you are presenting – they are resisting you. Maybe their history with you makes them wary. Perhaps they are afraid that this will be “a flavor of the month” like so many other changes, or that you won’t have the courage to make the hard decisions to see this through.

But maybe it's not you. People may resist those you represent. The statement, “Hi, I’m from headquarters, I’m here to help,” often leaves people skeptical. If you happen to be that person from headquarters, you’re going to have a hard time getting people to listen to you.

Whatever the reasons for this deeply entrenched resistance, you can’t afford to ignore it.

People may understand the idea you are suggesting (Reason 1), and they may even have a good feeling about the possibilities of this change (Reason 2) – but they won’t go along if they don’t trust you.

So How You Can Turn Resistance Into Support?

Here are a few ideas to get you started addressing the various levels of resistance. And remember, all three reasons could be in play simultaneously.

Make your case

> Make sure people know why a change is needed. Before you talk about how you want to do things, explain why something must be done.

> Present the change using language they understand. If your audience isn’t made up of financial specialists, then detailed charts showing a lot of sophistical analysis of the numbers will be lost on them.

> Find multiple ways to make your case. People take in information in different ways. Some like to hear things. Others like to see things. Some like pictures. Others text. Some learn best in conversation. The more variety in the communication channels, the greater the chance that people will get what you have to say.

Remove as much of the fear as you can – and increase the excitement about what’s positive about the change.

> Emphasize what’s in it for them. People need to believe that the change will serve them in some way. For example, work will be easier, relationships will improve, career opportunities will open up, or job security will increase.

> Get them engaged in the process. People tend to support things they have a hand in building.

> Be honest. If a change will hurt them – downsizing, for instance – then tell the truth. It’s the right thing to do, and it stops the rumor mill from inventing stories about what might happen. Also, honesty bolsters their trust in you.

Rebuild damaged relationships – and tend to neglected relationships

> Mea Culpa. Take responsibility for things that may have led to the current tense relations.

> Keep commitments. Demonstrate that you are trustworthy.

> Find ways to spend time together so they get to know you (and your team). This is especially helpful if the resistance comes from “who you represent” and not just from your personal history together.

> Allow yourself to be influenced by the people who resist you. This doesn’t mean that you give in to every demand, but that you can admit that you may have been wrong and that they have ideas worth considering.

In a nutshell: There are three reasons for resistance to change. I Don’t Get It, I Don’t Like It, and I Don’t Like You. Understand them and you can change resistance into support.

Read more…

Case Study 9: The Payroll System That Cost Queensland Health AU$1.25 Billion

The payroll system implementation disaster at Queensland Health in 2010 is said to be the most spectacular technology project failure in the Southern Hemisphere and arguably the second worst failure of public administration in Australia’s history. The handling of the fires this year being first.

Queensland Health is the public sector healthcare provider for the Australian state of Queensland, located in the country’s northeast. It provides dental, medical, and aged-care facilities in Queensland, which has the most geographically dispersed population of all Australian states.

Queensland Health needs to ensure that adequate healthcare services can be provided in the most remote parts of the state, which has a population of 5.07 million across an area of 1.85 million square kilometers. Every day, the organization provides hospital services to approximately 40,000 people and is responsible for approximately 85,000 employees across 300 sites.

What began as an AU$6.19 million contract between the State of Queensland and IBM Australia to replace Queensland Health’s aging payroll system eventually led to over 35,000 payroll mistakes and will ultimately cost taxpayers a whopping AU$1.25 billion, which translates to approximately US$850 million.

When the system went live, a large number of Queensland Health employees, including doctors and nurses, were either incorrectly paid or not paid at all. It led to the resignation of the minister of health, industrial strike action and loss of staff members to other employers.

To download all my Project Failure Case Studies in a single eBook just click on the image.

Timeline of Events

2002

At this point in time Queensland Health used two systems for their payroll: Lattice and the Environment for Scheduling Personnel (ESP) rostering engine. Lattice and ESP were rolled out progressively over six years from 1996 to 2002.

Payroll departments were part of their respective districts. Processing of pay was undertaken locally and there were close working relationships between line managers and local payroll staff.

Whilst processing of pay occurred locally, the actual running of the pay was undertaken centrally; essentially, a 'hub and spoke' model was used.

Lattice required a substantial amount of manual interventions to accommodate the complex award and incentive structures within Queensland Health.

2003

In 2003 the Queensland State government formally established a government shared services initiative (SSI) mandating that all state government departments, including Queensland Health, replace their existing legacy payroll systems with a standardized software solution that incorporates SAP HR and SAP Finance. The overarching objective of the SSI was to consolidate technology and resources through delivering a high-quality solution with standardized business processes.

The SSI was expected to deliver the following benefits: (1) increased opportunities through enabling workforce mobility; (2) increased visibility into the cost of services; (3) reduced data duplication through the consolidation of systems; (4) reduction in costs associated with licensing agreements; (5) reduction of personnel; (6) achieve economies of scale; (7) enable the government organizations to focus on their core competencies, thus increasing the standard of service; and (8) consistency of HR and finance information across all government agencies.

2005

In 2005, just three years after the progressive rollout was completed, Queensland Health received notification from the Lattice system vendor, Talent2, that their existing Lattice system was becoming obsolete and was no longer going to be
supported, with services and updates ceasing on June 30, 2008. As a result, Queensland Health needed to consider replacing the obsolete Lattice system much sooner than it would have liked.

SSI decided that the system for payroll would be SAP ECCS and Workbrain. Accordingly, it was decided that Queensland Health would replace the Lattice I ESP system with SAP ECC5 I Workbrain as part of the shared services initiative.

2007

As part of the SSI, the Queensland government established CorpTech within the Queensland Treasury to oversee the standardized implementation across all state government departments.

CorpTech was responsible for overseeing the consultant selection process (Request for Information, Request for Proposals, and Invitation to Offer) and managing the consultant organizations. CorpTech sent out a Request for Information (RFI) on July 2, 2007, and four consultant firms responded: Accenture, IBM, Logica, and SAP. Afterwards, CorpTech requested detailed proposals from the aforementioned consultant firms on July 25, 2007.

Prior to the RFI being issued, CorpTech had managed the implementation of SAP HR at the Department of Housing, and SAP Finance at the Department of Justice. These implementations proved to be quite costly as a substantial number of consultant firms and private consultants had been utilized. Due to the large expense associated with the multiple consultant firms, the consultant methodology for the SSI was changed to the prime contractor model on August 16, 2007.

Subsequently, on September 12, 2007, CorpTech released an Invitation to Offer, and IBM, Accenture, and Logica responded. Ultimately, on December 5, 2007, IBM officially signed an AU$98 million contract to be the prime contractor of the SSI.

2008

Around October 2008, IBM had not achieved any of the "contracted performance criteria." It had, however, had been paid AU$32 million of its AU$98 million contract.

The idea to build a payroll system across the entire Queensland public service was now officially scrapped, but the decision was made to push ahead with a payroll system for Queensland Health.

2009

To cater for Queensland Health's specific business needs, including the complex award structure, retrospectivity, and concurrent employment, a significant number of customizations were made to both Workbrain and SAP.

Payroll and user acceptance testing was performed in parallel over a series of stages starting July 2009. The first test of the payroll compared the pays of only 10 percent of employees from all employee groups when performed in the SAP HR and Workbrain rostering solution as opposed to the legacy Lattice system, which resulted in an AU$1.2 million discrepancy in the biweekly payroll.

2010

A second payroll test occurred in February 2010, which only resulted in an AU$30,000 discrepancy; however, casuals and overtime claims were not tested. Queensland Health accepted the inherent risks and opted to go-live without full testing of all the functionalities of the system.

IBM continued to operate under varying scope and the state government kept signing off on the change requests. The project documentation reveals that prior to the payroll system going live, the project underwent four revised go-live dates and four separate stages of change requests, often done at the last minute.

By the time the system finally went live in March of 2010, 20 months after the original start date, the bill had already ballooned to AU$101 million.

Given the significant issues identified following the initial go-live, it was decided to establish a payroll stabilization project specifically focused on stabilizing the new payroll system. The four key focus areas for this project were: standardization and improvement of district and division business processes; payroll processing; payroll system performance; and support and communications for staff, line managers, and other key stakeholders.

2012

The cost of going live with a premature system resulted in more than 35,000 payroll mistakes, and by this point it had cost the state in excess of AU$400 million just to operate the system. KPMG estimated that the cost of making the system function for the next five years would be another AU$836 million.

2013

IBM should never have been appointed as the prime contractor in Queensland’s failed health payroll project, according to the finding of the Commission of Inquiry that investigated the bungled project. The inquiry, which ran for nearly three months at a cost of AU$5 million, heard from some 50 witnesses, including former premier Anna Bligh, former health minister Paul Lucas, and senior IBM executive Bill Doak.

The report, by Commissioner Richard Chesterman, was handed down on July 31 in the Queensland Parliament by Premier Campbell Newman. The premier described the project as "arguably the worst failure of public administration in Australia’s history."

The report was particularly damning of the procurement process that led to the appointment of IBM, and decisions made by senior public servants and contractors involved with the project.

The report also found the state government could not recover any funds from IBM for the failure of the project, and that the decision to reach a negotiated settlement with IBM rather than commencing legal proceedings was made without any proper analysis.

2016

The Queensland government was ordered to pay significant costs to IBM Australia after failing in a bid to recoup losses from the health payroll debacle.

The Newman government launched legal action against IBM in 2013, arguing the company had misrepresented its capability to deliver a new payroll system on time and on budget.

But IBM challenged the lawsuit and pointed to a 2010 agreement that the company said released it from the damages claim.

A trial was held in the Brisbane Supreme Court in 2016 with Justice Glenn Martin ruling in favor of IBM.

What Went Wrong

System availability

During the payroll cut-over period to the new system, there were significant issues with the availability of the system to payroll staff which reduced the processing time available. This created an initial backlog of payroll forms and unprocessed adjustments for the period just prior to the go-live date that grew over subsequent pay periods.

It took approximately eight months to process the backlog of pay adjustments and forms to return to previous business as usual (BAU) levels.

Performance issues

The degree of retrospectivity accommodated by the Queensland Health payroll system, whereby staff could submit forms for work completed up to six years ago, was creating significant payroll system performance issues.

System issues

As of 2 May 2012, there were 570 logged system issues, 76 of which were identified as having the potential to impact on staff pay. System defect fixes and enhancements were required to occur during designated 'major release' schedules, of which there were three scheduled per annum. There were some delays in addressing specific defects and issues due to the prioritization of other 'fixes' including the pay date change, changes associated with enterprise bargaining changes, legislative compliance changes, etc. There was a need to gain endorsement for an agreed longer-term approach to implementing key system changes so that the release windows could be utilized more effectively.

Overpayments and entitlements

As of May 2012, Queensland Health had overpaid staff AU$112.3 million, of which AU$16.5 million had been repaid and AU$3.3 million was waived, leaving AU$9 million outstanding. Queensland Health had an obligation under the Financial Accountability Act 2009 to recover these amounts; however, there was a moratorium in place preventing Queensland Health implementing Queensland Health-instigated overpayment recovery.

Queensland Health was required to fund fringe benefit tax (FBT) liabilities associated with overpayments, and this represented a significant additional cost burden to Queensland Health. While the previously agreed overpayment moratorium was in place, the amount increased by approximately AU$1.7 million every two weeks.

In addition to overpayments, the issue of employee leave and balances requires further investigation and analysis. PwC has conducted a number of reviews into leave balances and they have identified that up to 20,000 leave transactions are still outstanding since the move from the previous Lattice Payroll system across to SAP.

New business processes

Part of the implementation of the new system was further standardization and centralization of payroll processing, including the introduction of central processing teams and a centralized pay run. As such, the key linkage between the districts and their local payroll providers was severed — payroll staff were required to process unfamiliar rosters for staff members across the state.

In addition, fundamental differences in how districts and line managers were providing pay information and rosters were identified, with each district continuing to provide the information in the format they had developed locally (this was a continuation of what had occurred with the Lattice system; however, now the payroll officers responsible for interpreting the pay information from the districts did not have the local knowledge or relationships that had previously assisted with the interpretation process).

How Queensland Health Could Have Done Things Differently

The key findings from the auditor general's report were as follows:

Project governance

Project governance prior to go-live, including managing relationships with key
Stakeholders, was not effective in ensuring roles and responsibilities were clearly
articulated and in ensuring there was clear accountability for efficient and effective
implementation of the system.

The governance structure for the system implementation, as it related to CorpTech, the prime contractor, and Queensland Health, was not clear, causing confusion over the roles and responsibilities of the various parties.

Management of the project became even muddier after it commenced. Numerous agencies and boards divided oversight and authority, causing significant confusion which, in the end, rendered them all "ineffective in establishing a shared understanding of stakeholder expectations in relation to the quality of project deliverables":

> The Solution Design Authority (SDA) (which, during this period, transformed into the program delivery office (PDO) of the state's CorpTech IT division);

> The Queensland Health Enterprise Solution Transition (Queensland HealthEST), the state's information technology management program and acting project manager (which inexplicably retitled the "Interim Solution" as the "Queensland Health Implementation of Continuity" (Queensland HealthIC) — no confusion there!);

> The executive steering committee (ESC), which included personnel from CorpTech as well as the shared services agency (SSA) and the Department of Education, Training and the Arts (DETA), and

> The "Release Steering Committee," which answered to both the ESC and CorpTech and counseled its chair regarding the development of the Interim Solution.

While there appeared to be lots of oversight of the program, Australia's auditor-general reported that "it was not clear which Accountable Officer had responsibility for the overall governance and successful completion of the whole project."

Scope and requirements

There was inadequate documentation of business requirements at the commencement of the project. The absence of a periodic review of the business needs contributed to subsequent difficulties with system testing and the implementation of a system which did not meet the needs of Queensland Health's operating environment.

The complexity of the project was immense and involved the management of over 24,000 differing combinations of wage payments and withholdings for over 80,000 workers and subcontractors spread over 13 contractors and multiple industrial agreements. Because of the fear that the existing system was in imminent danger of immediate failure, IBM agreed to take just seven months to develop and implement an "Interim Solution" to tide the agency over until a full replacement became operational.

Within that seven months, only two weeks were set aside at the beginning of the project to scope out the "critical business requirements" needed by the agency and the digital solutions that would respond to those demands. Not surprisingly, the lack of identifiable objectives was a significant cause of the project's abject bungling.

Testing

System and process testing prior to go-live had not identified a number of significant implementation risks, and therefore, the extent of the potential impact on the effective operation of the payroll system had not been fully understood and quantified.

Neither system usability testing nor the validation of new processes in the business environment were performed. As a result, Queensland Health had not determined whether systems, processes, and infrastructure were in place for the effective operation of the new system.

Business processes

A number of critical business readiness activities and practices were not fully developed prior to the implementation of the new system. Several changes to payroll administration practices including the reallocation of processing duties within payroll were introduced at the same time as the release of the SAP and Workbrain systems.

Standardization

The implemented Workbrain (1,029 customizations) and SAP (1,507 customizations) systems were heavily customized and are not operating optimally in the Queensland Health environment. Customizations are costly to manage, increase risk and impact on system performance and should be minimized where practical.

Supplier

Despite its affiliation with a global digital leader, this was IBM Australia's first attempt at delivering a project of this size. That fact was not helpful considering that Queensland Health was probably the most complex of the Australian agencies needing the overhaul and was perhaps not the best candidate for IBM's first go.

Layer on top of those contributors the reality that the "Solution Design Authority," the state agency with the responsibility to define and maintain the scope, architecture, and design of the new system, was "passive, perhaps lazy" about communicating its requirements for a payroll system. Before project development began, the Solution Design Authority accepted IBM's "incomplete, ... unsatisfactory scope [of work] documents" as-is and with no questions. The project was off to a horrible start.

Closing Thoughts

As a consequence of Queensland Health’s disastrous payroll implementation project, the Queensland Government changed their Information Technology (IT) strategy and governance procedures.

Furthermore, the Queensland Government IT audit specified a series of constraints
that must be placed on high-risk projects, which include the following:

1) project management personnel must be of the highest quality;

2) rigorous application of the Queensland Government project and program methodology;

3) the project must be approved by numerous chains of command, and

4) a reporting regime is to be established to increase the visibility of the costs associated with IT projects.

Being a state government department in the healthcare industry, Queensland Health is by definition already riddled with substantial layers of bureaucracy, adding to the complexity and increasing the difficulties associated with decision making, visibility, and accountability.

And these reforms, whilst necessary, add additional layers to the governance process, increasing both the number of bureaucratic decisions and the degree of red tape.

Consequently, both client and consultant organizations have been more cautious throughout recent technology projects in the public sector due to the increase in compliance which leads to project delays, and increased project costs.

Thus, aside from the financial and societal implications associated with the Queensland Health payroll implementation failure, the failure has also had national, industry-wide ramifications.

But do we really learn from these massive failures? Looking at the long list of big technology projects gone wrong after this one, I doubt it.

Especially in the area of public services.

Other Project Failure Case Studies

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

> To download all my Project Failure Case Studies in a single eBook just click on the image.

References

> Queensland Health Payroll System Commission of Inquiry Report (2013)

> KPMG Review of the Queensland Health Payroll System (2012)

> Rebekah Eden and Darshana Sedera, The Largest Admitted IT Project Failure in the Southern Hemisphere: A Teaching Case (2014)

> Raul Manongdo, Queensland Health Payroll system – A case study on business process management and application enterprise integration (2014)

Read more…