Forfatter: Kari Holmen

Any large change project is started as soon as key stakeholders and the board of directors have been convinced that initiating some big change is a really, really smart investment. The business owners foresee some utopian future – Minority Report Style – in 5 years time. Your young, hip CDO bought into your nifty slides with some stuff on «going agile» and design thinking. with some sprinkles of AI on top. Least – but not last – your CFO is finaly happy with the NPV after some busy nights tweaking your excel. And the parameters you have been tweaking are #FTEs, periodization and hourly rate…

Those parameters represent human beings.

…human beings with diverse professional background, network and experience. Their skill set will be extremely varied, they will be of all ages and probably speak many languages. Their incentives will be very different; some will see the project as the best thing ever happened to them, others will be very reluctant to contribute – perhaps even hostile, and there will guaranteed be a couple of *meh*-guys and gals.

Let’s just be clear right away – the hourly rate is the least relevant factor deciding who you will need on your team.

The problem is that there is a good chance that when you walk out of that board room with project and budget approval, the project team is still a bunch of FTEs in that brilliant excel of yours. And you need to ramp up and deliver on those quick-wins you just promised. Basically – you are way up shit creek.

There is no easy way out of the «I have no team» predicament. If there is one thing you will deeply regret trying to fast track through, it is the hard work of onboarding the people you need to succeed. This is the one area where the Pragmatist shows some signs of fundamentalism. Here are some ground rules you should have thought about before promising a delivery in a month or so…

You will not be able to onboard loads of people over a very short period of time – even if your plans and estimates state the opposite

Now you might – through some magic formula – have been able to get hold of a bunch of competent people to your fab project all of a sudden. You are still in trouble. Absorbing loads of new project members over a short period of time is almost impossible – they need to get to know each other and get to know the scope of work. They need to understand the goals they are supporting. And – they need to understand and take ownership of their own contribution.

Allthough Fred Brooke coined his law almost 50 years ago, it is no less relevant today. It might be a bit of an oversimplification, but still – there is no way you will reach that massive launch 3 months from now if you are seriously delayed. Adding more people only makes it worse. You’re gonna have to find out if the delay is real (and why), or if your plan is simply too optimistic in the first place.

There are other factors to consider when ramping up as well:

• The critical go-to people in the organization are not idly waiting for you to call them to action
• Recruiting people from the outside (be it future employees or contractors) is time consuming and requires management capacity, and the risk of making poor choices increases big time with a huge recruitement backlog and little time. The cost of recruiting the wrong people easily overruns the cost of not finding anyone.
• There is a lot of practicalities to think about as well – where are their desks? Do you have the work environment needed for several teams to collaborate? Have you ordered those fun t-shirts?
  
  So basically – getting actual throughput and outcome isn’t done right away. Don’t fool yourself, your stakeholders or worst of all – the people working for you.

Your core team members are more important than the project manager and the project office

I would spend initial effort on securing the following:

• making sure your delivery teams have strong triumvirates with a solution architect/tech lead, a team leader and a product owner/functional dude(ette). And make sure they have the time to get to know each other well, and get to know the troikas in other teams the need to work with. Let them have some SPA-time together.
• Some kind of terrier who manages the scope, progress and makes sure the project can deliver stuff frequently (even if your contract and MS Project plan indicates milestones every half year…)
• someone managing the user/customer perspective and insight from day 1
• Your project office should be strengthened with someone introducing and further developing project wide tooling fit for purpose for the kind of project you are running (see rule #4)
• if your project involves some infrastructure stuff or new platforms, you’ll probably find down the line that you need Someone who truly understands the risks and security aspects of your overall solution. You won’t find that Someone. Just a heads up…

Make it a punishable sin to utter the sentence «After the project is completed, we will handover to maintenance, support and operations in the line organization.»

Now, you personally might see yourself spending a couple of months on some tropical island post-project. This is not the case for pretty much everyone else involved with whatever your project delivered. Not to forget whatever has NOT been delivered, and all the hacks and not-so-temporary solutions. Most of the life span of any new technology or products you have introduced will be after the project has had that last Friday afternoon beer.

You need to make sure the core of your team(s) constitutes the long-term setup. Not a temporary project staffing that will be phased out after 3 years when they are «done». You will never get a better chance to get to know the technology and solutions the project introduces than being part of the project. And the «you build it, you run it» mentality is a lot better than «you build it, you get to run away if you finish on time».

Onboard the people who know your legacy systems and current functionality well

You probably had some slides in your breathtakingly great presentation to the board about not replicating the current complexity. Get rid of legacy. Start with clean slates. Do a proper clean-up. Giant leap to the cloud. And so on… All good. Wish life were that easy.

Two years down the line when you realize that initital big bang plan some management consultant suggested was kinda dumb, you will have to have some messy Plan B. Guaranteed with loads of legacy components. You will need those Cobol guys that you have promised early retirement.

And loads and loads of business rules do not go away simply by replacing technology. Those rules are probably not documented, they are the result of 30 years of adjustment and it is this one guy who have programmed them who is actually aware of them and understand the consequences of changing stuff. And what your test cases need to be.

I would spend a lot of time motivating the people who know and work with the existing systems and processes to contribute to the projects goals. Their knowledge is important, and they deserve clarity about future roles (or not…).

….and don’t forget that the «legacy people» most likely have been reporting increasing risk due to technical debt and lack of funding the last 20 years. They don’t sleep well at night, and are worried about the consequences of Ebay running out of spare parts. They will be truly incentivised by reducing this risk – and being a part of the future solution. Maybe you should add increased sleep quality to your project goals?

Communicate all of the above to stakeholders and make them understand; or actively seek stakeholders who do already.

The perfect stakeholder will challenge you on the people factors and say stuff like «there is no way you will be able to onboard people that fast», «I want my most critical girl to be a part of this», «who can I talk to in the project to increase my understanding?» and «how can we in the Steering Group be a valuable part of your team?»

Basically – great people make awesome shit.

Having been convinced to lead a large change program, you will quickly find that the devil tends to reside in the details… You suddenly find your self moving from a program scope that fits on 3 PowerPoint slides to 20 people addressing detailed design, coding and testing with thousands of Jira tasks popping up all over the place. Execution of the change program will uncover large amounts of “bits and pieces”. The amount of changes soon becomes unmanageable. The feeling of being completely overwhelmed seeps into every nook and cranny of your program organization. You start regretting not staying in your comfortable position as line middle manager with a stable 9-5 job doing compliance reporting.

All the good intentions of simplification, modernization and platform uplifts seem to be easily forgotten when the actual deliveries are being designed. “Nice-to-haves” start to become “must-haves” when requirements owners are faced with functionality being left out or post-poned.

You also realize that you are transforming an area that has been neglected for a long time. Business and IT owners seem to think “finally! My turn! It’s time to get everything done, and then some…” as soon as the funding was approved. This might be their only chance this century to get a particular feature.

Oh yeah, and as time goes by within the cozy walls of your large change program, the world has the audacity to move along with no regards to the consequences for your progam; even if your CEO has said you are doing the most important job in the company. Your original scope might not be robust enough to withstand disruptive threats to your company’s market shares, major regulatory changes, or the introduction of another change program even more important than what you are managing. Handling these kinds of changes if you are not rigged to efficiently change your scope will be a nightmare, probably a full stop, audit, then maybe restart situation.

Finally, with the “too big to fail” initiatives the actual benefits of implementing changes tend to be forgotten along the way. They are either drowning in macro-economic perspectives, or an original hypothesis on benefit realization trumps the experiences building up during project execution. As the project moves along, the people designing and implementing the solutions get better insight into opportunities and weaknesses. They are better positioned to define actual benefits than an upfront analysis based on… well probably pretty much nothing tangible…

Large change programs need to implement a strong governance system to manage the overall scope and the benefits associated with it. The governance system must cater for adjustments of goals as the program learns and external forces drive changes in expected outcome. 

This should be done in combination with a well-communicated stepwise approach to deliveries, continuously challenging the actual benefits of the work to be done, and having a sober approach to when a project or project deliveries should just be deemed business as usual and managed by the line organization (business and IT).

Oh yeah: if your agile-schmagile backbone now yells “hey hey hey – “strong scope and benefit governance! That’s waterfall! This is the Devil’s work!”, there is nothing stricter than regular backlog grooming. «Governance» and «scope and benefit management» does not automatically imply huge spreadsheets, ITIL, 1998-style change management tools or incomprehensible business case models. Modern tools for planning and assigning tasks, running automated tests, documenting decisions etc are great, but need to scale to program level. and be well aligned with systems or vendors not up to date with this way of work.

There is also usually some work to be done to convince PowerPoint and Excel loving program managers to embrace modern tooling originating from the IT world. It might seem like a techy detail to them; not something they should be bothered with. So show them the benefits. The cool graphics on stats and ways of monitoring progress. The PowerPoint integrations and plug-ins. They’ll love it!

Now, all this seems pretty straightforward. Trust me, it really isn’t. Some stuff to keep in mind when after finishing the bottle of champagne celebrating investment approval:

• It takes time to set up and introduce program level systems and tooling, and most plans tend to underestimate or simply ignore the effort. 2 years down the line when everyone feels the strain of not having done this properly in the beginning, is probably not seen as a good time to start…
• Aligning scope across teams or sub-projects is notoriously difficult, especially if you are making changes to legacy systems. Having worked hard to make teams as autonomous as possible in the beginning will pay of, but it requires that business and IT are well aligned and present together in the teams
• Benefit tracking for large platform projects or major systems renewals is difficult compared to programs dominated by new features or product development
• If you are dependent on deliveries from vendors, the flexibility you aim to build into your scope and benefit tracking may be severely restricted by a contract or a vendors own change and release management regime
• You will need to manage different views on both scope and benefit tracking – your developers, your controller and your steco probably do not share the same hands-on experiences, but they all need to get connected through some magical system
• You will need to integrate in a pragmatic way to systems and organizations impacted by your change program, but that are not a part of it. They will most likely have their own change management, and will not have the bandwith or see the needs to adopt to your structure

… and finally – don’t forget that probably a major part of your scope and benefits are related to organizational changes. New processes, Customer features, products to be launched or terminated, new roles and collaboration, training and business support etc. Make sure the guys and gals working with those parts of the change program are tightly involved in setting up your system. Otherwise it will probably be dictated either by IT people og PMOs, resulting in either something too techy or too bureaucratic.

Most large business and/or IT transformations require a migration of customer or user data from the old to the new systems, and a plan for how to replace old systems with new ones – both from a user, process and technology perspective. 

Now, the term «migration strategy» in the heading is – at best – confusing; maybe even misleading^*). I just struggle to find a better term. I am referring to the complex matter of moving your business, users and organization from one technology ecosystem to another; partly or completely replacing the existing. Often, and preferrably, in steps; making this all the more complex.

There are several aspects to this:

• How are your customer relationships moved from one ecosystem to another?
• How are the users of your systems impacted?
• how are your business transaction managed throughout the change? How do you make sure that you do not lose money, and that your customers do not get any unpleasant surprises?
• How do you migrate data between systems? And how is data integrity upheld?
• How do you grow your new ecosystem? on the back of your exisiting, or on the side?
• How do you roll out changes, and how is the roll-out strategy aligned with how you do technical development and releases?
• And much, much more…

Fundamentally the migration strategy will dictate the end date, duration and cost of the project – and more importantly the timing of benefit realization and impact on the organization. Hence, the migration strategy has to be decided as a part of project initiation for the Business Case to be correct.

You need to guide your stakeholders and decision makers through some choices that will heavily impact your overall plan; your organization, benefit realization, risk profiles, communication, business plans and go-to-market strategies, etc. You will also need to explain the consequences of the different choices, and the dilemmas associated with them. And there are no silver bullett solutions here – you can bet your bottom dollar on that…

Some areas that need to be discussed with stakeholders are typically:

• Will your system replacement impact your customers? And if there is customer impact – are you planning on combining the replacement with launches of new products, rebranding, new features etc?
• How are the company plans for market launches aligned with your project plans? What is on critical path?
• Do you aim for a greenfield approach or brownfield?
• …and if you have decided on greenfield because it seems very convenient and looks nice in PowerPoint, are you really, really sure it is possible? And is the field still green a year from now?
• Do you want to minimize the impact on system users, or is the move to something completely new and shiny your main selling point?
• How do you manage co-existence? Do you want to expose your users or customers to a co-existence, or should it be hidden in some way?
• Is the change and replacement triggered by changes to the physical environments? e.g. are you moving offices, data centres or similar? Does this give you some oportunities for renewal and actual greenfield approach that you shouldn’t miss out on?
• Do you need back-up and roll-back options, reconcilliation and parallell runs to verifiy outcome etc?
• How is the organization impacted? Is there a need for major changes to competence profiles; are cultural aspects an elephant in the room? How do you build ownership to «the new stuff», while «the old stuff» (and the co-existence) remains business critical for years and has to be properly managed?

…and perhaps the most important… since you are a bright and shining example of perfection and followed rule #1 – have you found a clever way of combining the need for a stepwise implementation with the need for an overall strategy on how to identify the right steps and how to order them? i.e. – do you have a migration strategy or just a first step?

^*) Oh yeah. The reason I am saying that «migration strategy» is not a good term, is because people usually start discussing staging environments and data mapping, and – understandably – think it is way, way to early to start designing that during project initiation…

The majority of large change programs or projects will reach a cost and/or time overrun down the line.

All seasoned project owners and managers know this and plan for it. They will add some slack in the timeline, there will be dedicate buffer in the budget etc. If you are one of those who run large change programs for a living, you probably do Montecarlo simulations in your spare time – as the crazy project nerd you are.

However, at some point, going over budget or postponing launch dates will become unacceptable for the key stakeholders. AND If the project is big enough the «key stakeholders» are the Board and the CEO/CFO.

Likewise, large projects running over several years will be exposed to sufficiently large external forces that require a change of project scope. This might impact the urgency or the focus of the original business case – if revenues are falling drastically, cost reductions might be much more important than the original feature oriented scope.

So even if there is a genuine will to take some risk and reduce quality expectations (the only levers left when cost and time are exhausted), there will be only two viable options on offer – reduce the scope or stop the whole ting.

Now, you might be tempted to go with the second option. Stopping sounds great! You can get some well earned vacay, and perhaps even catch up on the webinars on Cloud-something-or-other you have been postponing for 5 years.

Not happening. Too many stakeholders with – well – a stake to fall upon or even worse: lose face. There is even a term for this behaviour. There are real and painful financial consequences. Stock market frowns. Media writes about you – and not in a positive way. If you spot the scope challenges early, you may be able to maximize value; but if you wait too long you will have to look for whatever is salvageable; including the wording on your own epitath.

Therefore – running a project that needs to complete the whole initial scope in order to be completed successfully without full rollback will most likely fail spectacularily – one way or the other. The following is a summary of how I usually approach this, or wish I did in the past…

Acknowledge and accept complexity and continuous change

Probabably the most essential way out of all mess is to acknowledge that there is no end to change in your technical ecosystem. There will never be some amazing nirvana state where everything is DONE. You will always live with different generations of patterns, technology and organizational capabilities. Everything is in some way «legacy».

Managing a hetereogenous topology is at the core of all of your operations; in the past, now and in the future. How you manage your architecture and your investments must deal with these facts of life; not try to enforce an impossible state of perfection.

Invest (time, money, resources) in actually managing the scope across heterogeneous landscape

Quite surprisingly, many large projects seem to fail already from the getgo in this area. It never seizes to amaze me that so many projects that have spent years getting all analysis, business case and commercial processes through the system, seem to ignore the need for some form of ramp-up and initiation. Including practicalities on managing scope across different teams and if necessary – vendors.

On the other end of the scale you have the Excel-fetishists who think 3672 requirements in a massive, shared spreadsheet implies that they are «managing the scope» in a good way.

You need to make sure your plan caters for setting all this up. Don’t just leave it to your PMO to make an advanced spreadsheet by Friday and then check the «completed» box. You will need to agree on a lot of stuff – level of detail and break-down hierarchy (epics – stories – tasks seem to be dominating these days, but there is probably something new and shiny I haven’t heard about), ownership, coordination and meeting places, reporting, dashboards and automation, exception handling and yes – scope change. How is this reflected in the day-to-day work in your teams or vendor interfaces?

I still haven’t seen any magical solutions for scope management in large projects, but the features in integrated tool suites like Atlassisan are fairly strong. They give better overall transparency and places ownership where the work is actually done; moreso than traditional project management tools that tend to be more top-down. The dashboards with right use of plug-ins are pretty cool as well. There is also an added bonus if you can get a strained line org on your side by funding some long needed uplifts in tooling, and sponsor editorial staff for your wikis and jiras and stuff. Most IT people see the need for this kind of tooling, but tend to struggle to get the priority to set it up properly and manage the content in a good way.

And then there is the communication aspect of scope management. It should be fairly easy for stakeholders to understand at least the epics in your scope, and you should avoid internal lingo that is only known to the guys working with the technical details.

There is a lot of best practises out there in this area, but it seems not to be that often visited by very senior project and program managers.

Acknowledge that there are different cultures and Way of Work

A part of the complexity in a heterogenous landscape is refleted in the Way of Work, and how changes to systems are made (or not made, in some instances). You will find everything from:

• Autonomous development teams with a strong ownership to their own backlog, goals and progress
• Systems with this one guy that just fixes stuff
• Outsourced services with strict 2004 style change management processes and yearly release-cycles
• Systems no one has touched in 10 years
• Completely new stuff that still awaits permanent staffing and people are still on training classes

This means that even if you have this great Jira-rig in place, a lot of the required changes will never be triggered and completed by something assigned in Jira… You will need to work with the impacted areas, understand their way of work, and adjust methods and co-working – on both sides.

Beware of the chicken game

Problably the main cause for the long overdue realization that there is a need to reduce scope, comes from different parties being very reluctant to be the first to admit that they won’t make it. You’re there in a status meeting, everyone reports green, and no one wants to be the first to raise their hand (or change the color of the status-thingy in the Powerpoint report to red). This is particularily the case with vendors – even worse if there are multiple ones – and penalties looming.

There are a couple of ways to avoid this, ommitting the obivious one of avoiding the massive scope and «deliver all or fail»-trap in the first place. Basically it is about a combination of trust and mutual transparency, and making sure contracts are not set up to encourage the wrong behaviour. If your contract is full of huge milestones where payments are due, and an associated penalty regime, your vendors would never raise their hands and admit some kind of trouble, if they have the slightest inkling it is a problem shared with others – including you as the client. Usually you end up with the problem anyway.

The combination of fixed price, waterfall, a massive scope and many dependencies is a commercial set-up for total failure. Even if you think you did a great deal when signing.

Convince your key stakeholders that there is no shame in rethinking project approach

Finally – if you have reached the point in time that everyone admits that something drastic has to be done, it is probably not sufficent to address the scope. You will most likely need a more fundamental rethinking of how you approach your deliveries and what methodology you use.

In order to avoid the same happening again a year down the line, you will need to embrace frequent deliveries, a more benefit driven approach etc. Basically modernizing and structuring your way of work; not only the scope. You need a time-out.

The business case associated with such a time-out is probably very good, if your controller is on board with the math. Revisit your methodology and tooling. Look into your project set-up and roles. Renegotiate (or terminate) your contracts. Convince your vendors that changing the fundamentals of the contract to deliver step-wise and have more flexibility to change scope as you learn and the world changes is so much better than calling both parties’ legal departments. The amount of wrong choices going forward is proportional to the number of ties on both sides of the table in these kinds of disputes.

Project owners, project managers, vendors, executive consultants – you will all have to digest a couple of camels in order for at least something to succeed. Just get over it; and then get to it.

Oh yeah, and kick the executive consultants to the curve. They probably got you in this mess in the first place.

A vast majority of old school enterprise guys and gals like me probably have a hidden shrine somewhere in our basements in honor of Kotter. His 8-steps process for leading change has been one of the most influential self-help books for enterprise architects, IT strategist and CIOs struggling to find a way to explain to executives that something has to be done with all the legacy mess and out-of-control modernization backlog. The accumulated number of powerpoints structured around these 8 steps probably stack up to a mile or two. 

Quite frequently however, the change that has been instituted has resulted in some mastodon of a project. With a massive scope to finally replace everything in one simple, beautiful black box of a «smart» contract that the CPO convinced the CEO was a great idea. All the while quoting you and the great vision you presented a fortnight ago. Yippi! 

So there you are – the sucker who managed to convince the stakeholders that change was oh, so necessary, but sort of missed the part about how to execute. What to do – stuck with a Too-Big-To-Fail program that every engineer blames you for? Well, at least the Pragmatist has a couple of rules on how to minimize (well, sort of, kinda…) the damage. Actually there are five of them, with five strong runner-ups. 

Now you might think “hey! These are Captain Obvious’ top 5 rules! How dare you steal his intellectual property!”, but the amount of tax dollar money wasted due to not listening to the good, ol’ capt’n is staggering. 

So here goes. Let’s start with number 1.

#1 Aim for a stepwise implementation approach.

Creeping scope delays, risk related to large “big bang” releases, unmanageable cost increase etc are all issues related to large projects with very coarse staging, or no staging at all.

These issues are usually – no, always! – best managed through splitting the main phases into smaller steps; catering for proven results along the way.

An added bonus to this approach is the ability to celebrate success through actual deliverables. You can also adjust the target solution as you go along.

“Well, duh”. This should be project 101. Still, it seems that gravity pulls large changes towards few stages/steps, and large roll-outs. Maybe less so in recent years; but still. There are probably many reasons for this phenomenon:

• Developing a practical and feasible plan that combines decommissioning and refactoring legacy complexity with development of “new stuff” is extremely complex. There are loads of compromises to be made, many temporary solutions and a continuous flow of “slightly less than good enough” in order to actually deliver something of value. The only best practise pattern to solve this mess is Hard Work, and for some reason that is not necessarily on people’s list of preferred patterns.
  
• There is a cultural divide between the agile world and the realm of more classic projects. There seems to be an unwillingness to find practical hybrids that cater for the need to use the best of these two worlds to solve complex and effort consuming problems. The result is a complete lack of best practices.
  
• Managing a stepwise approach with the ability to adjust the direction throughout execution seems to be a headache when there is sourcing involved. There is often a somewhat old-fashioned approach to procurement; particularly within the public sector. There tends to be a preference to using hard milestones in contracts for leverage, instead of something mutually beneficial that will give flexibility to adjust timelines.
  
• And finally perhaps the main obstacle: executives sometimes (too often?) have a combination of impatience and illusions of grandeur at the core of their leadership philosophy: This makes large deliveries – in combination with a «work smarter, not harder» attitude – very attractive to decision makers. Perhaps even have the two only phases run with a significant overlap? Will be cheaper and finished earlier!

Being the pragmatic IT middle management 40 something you are, you just have to deal with this, and take the bull by the horns. All though you probably should not have gone along with a huge change program in the first place – at least make sure you influence the implementation and migration strategy and the roll-out plans in the program. There is research to back you up. Loads of experience. Probably also a few theoretical patterns and “best practices”, but in the end there is just Hard Work in front of you. 

Some pragmatic tips and hintson how to convince your stakeholders:

• Refer to research and facts; if you have some McKinsey-facsimile you can use; that is great. Use phrases like “excelling at core project-management practices, such as short delivery cycles and rigorous quality checks”.
  
• Focus on the pros of the stepwise approach (early benefit realization, quick adaptation to market dynamics, risk reduction, user oriented approach), and don’t make all the challenges ahead too dominating. It IS complex to do a large change initiative with legacy dependencies in steps; but it just isn’t feasible any other way. So focus on risk mitigation instead, and save the (albeit great!) complexity and risk slides for the architects and team leads; not the CPO and CMO.
  
• Separate the presentation and decisions on the overall staging approach from the details of the actual plan. The plan will change frequently when you start (and learn from) actual design and implementation work, but the overall approach should be quite constant. You probably need to find some kind of logical dimensions to slice and dice the scope into; functionality, domains, products, users, customer segments, features, technology, something. This will be your approach, or staging strategy if you will. We will get to that in #3. (…the suspense!)
  
• Make sure there are dedicated resources handling the dependencies and different kinds of temporary solutions and technical solutions to actually make the solutions work. If you have fully emerged into the autonomous team-bonanza, make sure managing these dependencies are clearly stated in the team mandates, and that there is structured governance to manage it across all teams. Oh yeah, and make sure the teams have some grumpy pragmatists in their midst to challenge the “let’s solve everything through microservices!” hipsters.
  
• If you are challenged on the business case of a stepwise approach (“this will take too long time and cost too much”), counter it with early and frequent benefit realization, add in risk calculation of cost overrun with half a year delay, and the financial consequences related rule #2. 

So there you go. Now run along and make those beautiful powerpoints!

…and on a final note: if it is impossible to find steps with manageable scope in combination with a high level, overall timeline that is acceptable for key stakeholders, the total scope is probably too large… Just sayin’.

Next time: “#2: Plan for downscoping/rescoping. It will happen. Really. It will».