Create a Lighthouse to Drive Your Transformation

I’m a firm believer in transformation through delivery. In my experience real change cannot be implemented without a vehicle that is used to drive it through the organisation and crash through existing barriers. 

Transformation is far more than just deploying new technologies for the sake of it. A genuine competitive advantage can only be gained through the combination of an organization’s culture, its strategic choices and way of operating. 

It’s about continuously enabling new and leaner operating models underpinned by flexible business processes, connected platforms, analytics and collaboration capabilities that enhance efficiency and effectiveness. 

It’s about searching, identifying and developing new technology supported business models and, above all, ensuring that customers and employees are at the center of whatever a company does.

A good way to start transformation through delivery is by defining a so-called lighthouse project early on in the process and letting your best people make it a success. A lighthouse project is a short-term, well defined, measurable project that serves as a model — or a “lighthouse” — for other similar projects within the broader transformation initiative.

This technical delivery project will show new ways of working and doing business combined with the use of technology and will help to identify organizational challenges that hinder you to do the same in the rest of your organization.

The 4 key attributes of such a lighthouse project are:

> It has high business value and visibility so it is less likely to be cancelled. A lighthouse project doesn’t need to directly benefit everyone in your organisation. But its value should be something that everyone in the organisation can appreciate and understand. It should have obvious results, such as “we have reduced the hardware purchasing budget by 70 percent” or “we have managed to increase our application uptime from 95 percent to 99.9 percent.”

> It has clear metrics. You’ll notice that the results mentioned above involve hard numbers. Collecting quantifiable data about your lighthouse project is important in order to make the demonstration of value as clear as possible.

> It touches multiple business units and silos to enable the identification of barriers and influence change.

> It has a hard deadline in the near future to focus the business and delivery team to provide pressure to break down barriers. You don’t want to wait years for your lighthouse project to be complete. Choose a project that can be implemented within a reasonable period of time—a year at most. Of course, you should be careful to balance time-to-completion with sophistication; don’t make the project too simple in order to make it faster to complete.

In a nutshell: A lighthouse project is the key to transformation because it shows everyone in your organisation what they can achieve by leveraging new ways of working, new ways of thinking, and using new technologies.

Read more…

Going Live Too Early Can Be Worse as Going Late

A significant part of my engagements involves post-mortems on large, failed technology projects. And out of professional interest, I study public project failures and write case studies about them. 

Based on my experience and studies, most of these disasters could have been prevented (or at least anticipated) based on the project’s available information.

While project teams are rarely surprised by the outcomes, sponsoring executives are often unaware of the impending tragedy until it unfolds – and sometimes at the expense of their careers.

One executive decision in particular can move your project from challenged to a full blown disaster. And that is going live too early with a business-critical system.

A well-known characteristic of large projects is that once “go-live” dates are planned and communicated it is hard to change them. There are multiple reasons for this. For example:

> Highly visible or public commitments may be difficult or embarrassing to come back from.

> Breaking contractual commitments may have significant financial consequences.

> Individual and company reputations may be damaged by not meeting a promised date.

> Significant costs may occur to continue the current solution beyond the cutover date.  These costs can include renewing expensive leases, licenses, or maintenance for equipment, software, or real estate.

> People currently working on the project may be needed elsewhere, creating a resource problem that would impact operations and other projects if the current efforts were extended.

Most of you have experienced such timeline pressures; they are real, and I do not intend to underplay them. But, as real and daunting as these pressures can be, they have to be balanced with the consequences that a premature go-live can have. 

You must consider both scenarios in your decision-making.

Estimating implementation timelines is an imprecise art, not a science. It is subject to error as well as risk and uncertainty. As your information systems become increasingly interconnected and sophisticated, coordinating changes takes time, patience, and hard work.

Systems often have substantial elements of organizational change that must be addressed before a go-live. If your new or changed system requires a meaningful change in how people do their work, significant time may be required to understand the implications of the change, modify processes, as well as user enablement through training and support. Changes in the processes may create downstream effects into other parts of your organization that must also be understood and dealt with.

Replacing all, or part of, an existing system can also be complicated by differences in how data is captured and stored between the old and new systems. The efforts and impact of stopping an existing system, converting and loading data, and restarting the new system are easy – and devastating – to underestimate.

Unfortunately, what happens often in large projects is that all these things are ignored as soon as the first milestones are missed. It suddenly is all about making the deadline, and not about doing the necessary work and mitigating these risks.

Below are a few prominent examples of what can happen if you go live too early:

> Case Study 13: Vodafone's £59 Million Customer Relationship Disaster

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

> Case Study 6: How Revlon Got Sued by Its Own Shareholders Because of a Failed Sap Implementation 

> Case Study 3: How a Screwed-Up SAP Implementation Almost Brought Down National Grid

> Case Study 2: The Epic Meltdown of TSB Bank

So before you find yourself pushing relentlessly for the go-live date, I encourage you to consider the following eight questions about your team’s readiness for go-live.

1) Is your system ready?

Has it been thoroughly tested? Is there an honest assessment of the quantity and priority of its known defects? Have business users weighed in with an informed opinion about the acceptability or the feasibility of workarounds for the known issues?

2) Are your upstream and downstream systems ready?

Have interfaces been tested fully? Are instruments in place to monitor traffic and identify problems? What would be the business impact to your system and your surrounding systems if there is a significant disruption of data flow or a significant error in the data? What are the consequences of data delays? Can the teams operating your upstream and downstream systems support your cutover date?

3) Are your users ready?

Have the implications of changes been thoroughly analyzed and communicated? Are users ready for the changes to their processes? Does the organization understand the secondary effects of these changes on downstream processes? Are user staff sufficiently trained on the new system? Will there be enough staff available during cutover to deal with the learning curve of the new system and processes and work through unforeseen issues?

4) Is your technology infrastructure ready?

Are you confident that there is sufficient processing, network, and storage capacity to support the new system? Are your help desk and operations people trained and ready?

5) Is there a go-live playbook or schedule?

Did you provide details of the steps required to stop the current systems, migrate data, convert interfaces, and begin processing with the new system? Are roles and responsibilities during cutover clear? Are the timings of the cutover schedule reasonable? Has there been a successful dry run?

6) How and when will you know that the cutover was successful?

Success here would mean not just all aspects of the technology, but also the impacts on the processes and the people who interact with the system. Has monitoring been established to provide early warning of problems?

7) What is the impact of a failed implementation?

Have you considered the failure modes of the new system and its impact to your business and that of your partners? Are there feasible workaround processes in place should cutover disruption be extended?

8) Is there a feasible fallback plan?

Can the cutover be aborted if significant issues are discovered? How long can the new system be in place before the cost and complexity of backing out of the system will be preventing this? What is the “point of no return” on the implementation? Is the fallback plan as detailed as the go-live plan? Has it been tested?

Before succumbing to the inertia and inevitability of a committed date, an honest assessment must determine whether the system and organization in which they operate are ready for the transition. 

So instead of focusing on the list of reasons why a system “must” go live on the selected date, have an honest conversation with executive stakeholders about the true status of the initiative and the potential consequences of a failed implementation.

In a nutshell: Going live on time should not be the default. Going live when the system and organization are demonstrably ready should be the goal.

Read more…

Another Great Leading Indicator for Future Trouble - Issue Resolution Time

I have a very simple metric for determining the health of a project or an organization: the age of issues. 

Issues are like fish; when they get old, they stink. 

A sure sign of a lack of leadership and upcoming trouble is old issues or issues that take longer than necessary to resolve. 

Issues are obstacles that get in the way of execution. It is the project manager’s role to resolve and eliminate these issues as quickly as possible regardless of the owner or the cause. 

If the project owner cannot solve it (or doesn’t try) it is up to the executive sponsor.

If an issue stands in the way of executing project objectives or makes it difficult for project managers to perform, it’s your responsibility as an executive sponsor to resolve it. 

If the project manager is the problem, it is also your responsibility to solve this.

Fix the root causes of problems and fix them early. 

What you want to avoid is a form of collective project amnesia where issues come up and never get resolved. 

Issues have a funny way of resurfacing when they don’t get resolved.

In a nutshell: Old issues and/or issues that take too long to resolve are an indicator of poor leadership and a great leading indicator for trouble in the future.

Read more…

A Great Leading Indicator for Future Trouble - Missing Milestones

I have done quite a number of inflight reviews and post-mortems of troubled and failed large system implementation projects. 

One pattern that emerges very clearly is the one of missing milestones whilst keeping the go-live date the same. 

It rarely ends well.

I see it again and again. Multiple important milestones are missed. Sometimes by months. And the ones that are marked as completed have their original scope reduced.

For example system integration tests (SIT) without all interfaces being completed and no production like data.

Or user acceptance testing (UAT) with systems that are not ready or contain so many bugs that end-to-end testing is not possible.

Astonishing is that in most cases both the project sponsor and project manager seem to be convinced all is “green” and it will work out until the project folds like a house of cards.

When you look at a typical large system implementation project it is still largely implemented like a waterfall. This includes ERP systems, CRM systems, Core Banking, etc. 

And this has not changed with the rise of software as a service (SaaS) offerings like Salesforce, SAP S/4HANA, Workday, etc.

Yes, the design and build phases are now iterative, but at a certain point your full solution needs to be tested end-to-end. This means one or more SIT phases and an UAT phase that includes all upstream and downstream systems and processes. 

You also need time to fix all the findings of your testing, and to do re-testing. If you are lucky one cycle is enough. Usually it is not.

You also need to train all your users and your support teams on the new solution and processes. Ideally on a solution that actually works. 

And when you are ready to go, you have a cutover phase from your old solution to your new solution. 

So yes, you design and build iteratively, but the rest is still shaped like a waterfall.

And this means that if you miss important milestones and you don’t change the go-live date you will steal time from the very important phases that come at the end of such a project. 

Starting these late phases without having completed the previous phase just does not make sense and will drive your test team and end users crazy.

Missing milestones does not mean your project team is doing a bad job, but they obviously underestimated the time it takes to do certain things.

Chances are this is a pattern that is repeated for the later phases of the project. 

So you will probably need more time for these phases as planned. Not less. 

In my experience there are only two probable outcomes of such projects:

1) They never go live

2) They go live too early 

The latter can be even worse as the first. 

See here and here for some prominent examples from multi-million projects that never went live, and here and here for projects that went live too early. 

You will find many more examples among my project failure case studies.

In a nutshell: missing milestones and not changing your go-live date is a great leading indicator for trouble in the future.

Read more…

Jobs to Be Done for CxOs in the Project Economy

We all have heard about the disruptions that are impacting our society and the business world: robotics, machine learning, artificial intelligence, shared economy, blockchain, big data, augmented reality, and so on. 

But, there is one disruption affecting our world that media and academia seem to have completely missed.

The Project Economy

For decades organizations have been run and structured in a very similar way: hierarchical; in which power, budgets and resources are divided over departments, the so-called “silos”. 

Management and management theory was focused on how to run and optimize the business best in an ever during quest for efficiency. Projects were an addition, but hardly ever a priority.

Today, due to the speed of change witnessed in the past decade, this model has become more and more obsolete. 

For many organizations the day-to-day running of a business will soon be carried out through automation and robots – and is already done so in many instances. Projects have become an essential part of any organization.

My prediction is that in the upcoming years, senior leaders and executives will spend much (maybe even most) of their time selecting, prioritizing and overseeing the execution of projects.

Ultimately, projects deliver value to stakeholders by solving their challenges, delivering products and aligning projects to an organization’s value streams. If done right, these initiatives also deliver financial and/or societal value.

This phenomenon is known as “The Project Economy”.

Jobs to Be Done

Taking the above into account there are a number of jobs that a CxO (like Chief Executive Officer, Chief Operations Officer, Chief Financial Officer, Chief Technology Officer, Chief Information Officer, etc.) will need to be able to do well when leading organizations in this project economy. 

Below you will find the (in my humble opinion) ten most critical jobs to be done for CxOs. 

1) Being an effective Project Sponsor.

2) Being an effective Steering Committee member.

3) Selecting the right Project / Program Manager for your initiatives.

4) Implementing change.

5) Executing a strategy with projects.

6) Selecting the right projects.

7) Prioritizing projects.

8) Killing a project.

9) Reviewing a project.

10) Recovering a project.

In a nutshell: In the upcoming years, senior leaders and executives will spend much (maybe even most) of their time selecting, prioritizing and overseeing the execution of projects.

Read more…

Can a Task Force Rescue Your Failing Project?

We’ve all witnessed projects in trouble—the ones that required a quick and firm intervention in need of help from a task force to bring it back on track.

No executive wants to be in such a difficult situation, especially not with one of his or her own projects.

But how do we, as the executive sponsor, handle saving a troubled project? Can it be as simple as mandating a task force?

Let’s start with exploring what a project task force is and when it could be useful. 

A project task force starts with a mandate given by the organization’s project sponsor or senior leadership to an experienced leader with the goal of finding the best option for resolving a particular problem in a very short amount of time.

A task force team is a small group, usually four to twelve people, that brings together a specific set of skills and experience related to the problem at hand.

A task force is a useful management mechanism that should be only used in exceptional situations. It generally requires disrupting other project activities and deploying the best people to solve the problem under possibly highly stressful and energy-depleting conditions.

So how do you handle this? 

I have been part of several task forces and have led a few as well. I have had both good and bad experiences. In order for task forces to be effective, you will need:

A Clear Mandate: It needs to be communicated to all stakeholders that the project is in task force mode, as well as who is leading the task force (see next point). You will need your stakeholder’s help in receiving quick turnaround times on information requests and decisions. You will need the best people in your organization for your task force team, so people need to understand it is urgent and important. 

An Experienced Leader: It can either be a senior project manager or a leader experienced with crises situations. Single leadership is the key to getting the job done! The last thing you would want is having two or more leaders debating how to drive the task force; one person has to call the shots.

An Expert Team: The task force leader will need to quickly assemble an expert team, formed with the best people who have the required field expertise to quickly understand and resolve the problem. The smaller the team, the easier it is for the task force leader to motivate and steer the team towards finding the right solution.

Laser Focus: The particular problem the task force is working on has to be clearly defined and known to the entire task force team. The objectives they will be working on also have to be clear to everyone involved. Several other project issues may come up along the way, thus, to be effective, the task force must remain focused on the specific problem.

Executive Support: At times, the reason a task force is needed in the first place is due to internal politics and resistance to change. One of the worst things that can happen to a task force is that they have no backing from their leadership to cut through this. 

Expectation Management: Many times, a task force can improve the status quo significantly, but you should not expect miracles. Further, you should strive to not communicate your desire for miracles upfront. Make clear to everybody that the goal of the task force is to find the best possible solution under the given circumstances.

A Short Time-Frame: Given the urgency and the high level of the task force team’s energy, they are only effective if conducted in a short time frame (a matter of days, or a few weeks). If efforts go on for longer, it is likely not a task force, as the energy and effectiveness will lower over time.

Simple Logistics: Due to the intensity and possible stressfulness of the situation, task forces require an isolated project space—or war room. This space needs whiteboards to facilitate brainstorming and for capturing the results of the task force (notes, action items, assumptions, decisions, solutions, etc.). Yes, we all learned during COVID-19 to cope with this remotely, and yes, for international teams, it is not always feasible either. But trust me, in a time of crisis, it really works better this way.

Solution Options: The task force’s outcome should include one or more options that lead to a solution to the problem, including a recommendation for the best option. This option, even if it is technically the best that the expert team can recommend, might not satisfy the risk appetite of the person or organization that has mandated the task force. Therefore, every option should also provide the related pros and cons.

Qualified Assumptions: Beware of unqualified assumptions. If the identified options are building upon assumptions that are not fully validated, highlight the risks or needs for confirmation before making a final decision.

A Clear Ending: To end the task force, its leader and the expert team will have to reduce the complexity and summarize the outcome of their work (options with pros and cons, along with assumptions and their risks or opportunities). Ultimately, the task force leader will communicate the outcome, confirm the decided solution, and conclude the mandate of the task force.

If set up and executed properly, a task force can be an effective tool to resolve crises situations in projects. 

Typically, these situations occur relatively late in the project when nothing else has worked. Interestingly, they usually work relatively well, as they are given the highest priority. 

Due to their ability to solve such issues, task force leaders are often celebrated as heroes. 

But task force teams work only at the expense of all other projects! All other projects endure even more pressure and are good candidates for further task force teams. Thus, they should be deployed wisely.

In a nutshell: A task force can be an effective tool to rescue failing projects if set up and executed properly.

Read more…

How a Transformation Office Can Help Your Transformation Initiatives Succeed

A new year has just started, but also in 2021 companies will be talking about digital transformation often. I think digital transformation is a terrible description for what is just another transformation. See my article “Digital Strategy Does Not Exist” on why that is. 

But we shall use the term for a moment to analyze the situation. Digital transformation is nothing new. It is a daily reality for all companies. Some are the disruptors and others are disrupted. And Covid made this even more clear. 

All understand that digital transformation—not evolution—is required to maintain a competitive edge. That is why so many digital transformation initiatives have been started around the world. 

But it seems that 70 percent of all digital transformation initiatives do not reach their goals. In 2018, of the $1.3 trillion that was spent on digital transformations, an estimated $900 billion went to waste. [1] 

Companies need to shift their approach to ensuring they reap business value and desired business outcomes from digital transformation initiatives. Across industries, most organizations are using standardized project management practices such as a traditional Project Management Office (PMO).

But digital transformation requires much more than status-tracking and risk escalation—it requires a robust capability that drives execution with a value-realization focus: A Transformation Office. 

This is not just semantics, not just a lift-and-shift, not just a glorified PMO. It is a truly different undertaking to ensure digital transformations deliver on their promise. 

And the same is valid for any other critical transformation initiatives your organization is planning. Not just digital transformations.

Transformation can take many shapes, from transforming business models to cater to a shared economy to transforming the way that critical services are delivered to clients. 

The Transformation Office

A Transformation Office enables organisations to manage multiple program and project management initiatives towards one common goal. It is more than a PMO with a fancy name – it’s about bringing strategy to life.

The Transformation Office is responsible for driving complex initiatives on both operational structures and the strategy of the organisation. It is a critical link between the executive vision and the work of the organization. 

Some companies call this function a Strategic Implementation Office, while Gartner refers to this as a Strategy Realisation Office. 

Regardless of the name, one element that sets a Transformation Office apart from most PMOs is that the C-suite proactively supports the Transformation Office’s mandate to transform the organisation entirely, which ensures it has the highest priority when implementing and affecting change.

They will be the strategic architect working with the CEO to integrate and drive and choreograph a transformation agenda. They will have to play the integrator function as well because often if you are driving customer agendas on one part of the organization, cutting costs in another part, going after a digital agenda in a third, all of those will be interrelated, and there will be interdependencies that someone will need to play air traffic controller for.

Core Competencies

The most effective Transformation Offices will house several core competencies necessary for successful transformation, including:

Enterprise Architecture to define an updated or even an entirely new structure for the organisation with which transformation activity can be planned around and clearly communicated to everyone involved. This includes Design Assurance to safeguard its integrity across projects and alignment with the vision set out in the business architecture. This critical role aligns IT and other support functions behind the business design.

Project Portfolio Management including prioritization to ensure investment flows to the highest value initiatives and that the investment method is transparent and collaborative.

Project Management to track, govern and manage the transformation whilst reporting progress.

Change Management to ensure users and other stakeholders adopt the changes that the transformation brings. 

Benefit Realization Management to ensure execution delivers the intended benefits and outcomes, by continually monitoring progress and adjusting to keep the delivery on course.

The Transformation Office not only sets the schedule and the tone of the transformation, but it also keeps score, with consistent ways of measuring and tracking business value. It ensures everyone has access to the same simple rulebook and is trained to understand its unambiguous processes and policies. 

The Transformation Office is a coach to help the organization grow and get better with the responsibility of ensuring that efforts are not stifled by old-fashioned bureaucracy that the company might have become accustomed to.

Single Source of Truth

Any organization undergoing a transformation will have a pipeline of improvements, subdivided into actions, owners, and dollars at stake. An important role of the Transformation Office is to ensure that all participants have a “single source of truth.” A transparent view of what flows through the pipeline and a central record of the progress of each initiative owner.

Tracking and approving initiatives can be done through a structured stage-gate process that goes from initial identification to final realization.

Armed with the truth, the Transformation Office has the credibility to spot potential conflicts or overlaps among work streams, raise the issues with stakeholders in its regular meetings, and work with owners and executives to achieve the best outcome for the business. 

Without this sort of planning and intervention by the Transformation Office to remove bottlenecks, one or two project teams can cost an organization millions of dollars.

Parallel Organization

The Transformation Office exists in addition to the line organization. Now why is that? 

Most organizations rightfully say, "We prefer that the line should just implement the change. The line organization needs to own and embrace the change."

And that's an understandable and very aspirational ambition that you should have for a well-run company. But the reality is that while in a transformation phase the line organization will need to change as well. 

The operating model, the kind of executives you had, the skills in the organization that made them successful in the past may not be the same as what you will need to have in the future. 

And so, as you are transforming the line organization, you will need this kind of office to create a bridge until the newly transformed line organization—the redesigned and transformed organization of the future—can actually inherit the initiatives and operate them smoothly.

In a nutshell: A well-executed Transformation Office can improve your transformation across four areas: value, design, execution and business adoption. Think of the Transformation Office as a risk mitigation insurance policy on your most critical transformation initiatives.

References

[1] Harvard Business Review, "Digital Transformation Is Not About Technology", March 13, 2019

Read more…