We (the global corps of IPv6 evangelists) have done the trainings (over 200 training sessions in about 45 countries in Africa alone and counting). We’ve done the conferences (several variations of IPv6 World, IPv6 Business Conferences, IPv6 Hours and Days at the Africa Internet Summits, etc). We’ve even done the global coordinated events—IPv6 World Launch. Governments have found it trendy to launch IPv6 Task Forces and come up with National Action Plans for IPv6. Now, almost more than 2000 network engineers (across Africa), thousands of hours of speeches and presentations, hundreds of blog articles and webinars later, where are we? The answer to put it mildly is: still booting up.

I am certain that if deployment were just a matter of technical skill alone, then at least half of Africa would have any where from 25–50% IPv6-enabled networks. Why? because in 75% of the countries on this continent, there are at least 2–3 engineers at at least one major ISP that have been trained in the critical knowledge and skills of how to deploy IPv6: knowledge needed to do an IPv6 infrastructure audit, creating an address plan, acquiring IPv6 prefixes, configuring routing, provisioning systems and how to choose transition mechanism. My own experience is that over the last 5 years, only a handful of engineers who have attended my classes have gotten back to me to say “hey Tamon, I’ve deployed IPv6.” In each case, those all fit the following profile:

• They are engineers who are high up the corporate ladder (CTO, co-Founder, Head of Networking etc).
• They have deployed IPv6 at the Internet edge and across the core. None had deployed to users or to public facing services.
• They had accomplished the deployment either on their own or using one or two enthusiastic colleagues from their team (typically those who attended the same course).

When I asked them why they have not been able to roll out IPv6 beyond the core and edge, their answers were almost unanimous: “That will involve dealing with other departments apart from my own and require resources that only management can allocate. Unfortunately management doesn’t get it.”

I’ve heard the sentiment in that last statement several times and in several variations that I created one of the world’s first IPv6 courses for managers back in 2012. I’ve since come to the realisation that the reasons IPv6 deployment in Africa (and I’m pretty sure in the other continents) isn’t getting past the Internet edge and core networks to the customers and services can be summarised to the following five:

1. Lack of RESOURCES: time, skills (people) and money
2. IPv6 deployment gets lost in the whirlwind of activity that is considered ‘THE REAL WORK’
3. Once initiated, the deployment team often has no RELIABLE INDICATOR OF WEEKLY PROGRESS. Consequently ..
4. Sustaining ENGAGEMENT in a project whose final output can only determined after 12 months (or more) is difficult
5. Maintaining individual ACCOUNTABILITY. Teams don’t do tasks, individuals in a team do tasks that add up to deliver projects

The resource-scarcity problem that plagues IPv6 (the reason there’s lots of partial IPv6 in the core and almost no user traffic) can only be solved by the senior and executive management of an organisation. It’s a hard pill for engineers to swallow and acknowledge that the world doesn’t revolve around our wits and engineering brilliance but on the pen-strokes and approvals of people we euphemistically call “The suits”. Nothing of significance can be achieved in any organisation without resources: skilled people to work at it, materials to support the work, time and money to oil the gears of labour and extrinsic motivation. These resources are controlled by “The Suits” and they must be influenced in order to give the IPv6 deployment project a slot at the resource-allocation table. Two key things are required to earn that slot:

1. A BUSINESS CASE: It’s simply WHY should we even deploy IPv6? The answer has to be better that the generic “because we don’t have any more IPv4 addresses” that’s the mantra of IPv6 evangelists. The effective business case is that which is contextualised to the organisation using the following generic themes
   • Implications of IPv4 exhaustion for the corporate or business strategy of the organisation (what are 5 bad implications of IPv4 exhaustion on our business strategy?
   • Benefits of IPv6 for the business strategy (what are the 4 key benefits that deploying IPv6 will have on our business strategy and business model?).
   • I’ve written before how an engineer could learn to make such a business case here.
2. A MANAGEMENT CHAMPION: this is an executive from the business side of the organisation who will own the project and ensure that IPv6 deployment project doesn’t fall off the radar of executive management and thus the resource allocation process. More details of what an effective manager does to drive IPv6 deployment can be found here.

No initiative can be successfully launched in an organisation if it lacks these two elements (unless you are the CEO in which case your only problem becomes execution, the second part of this post). IPv6 deployment is not an exception to this general rule. I dare say that if the internal IPv6 enthusiast/evangelist cannot find an executive champion (unless they themselves sit on the executive team and can do the championing), then the IPv6 deployment project will eventually fail or succeed mediocrely at best (IPv6 prefix announced globally for the past 5 years and not a single byte of IPv6 traffic passed in all that time?).

Launching (in terms of bootstrapping) a successful deployment IS a business/management problem, it IS NOT an engineering one. Executing and delivering a successfully bootstrapped (launched) IPv6 project is (predominantly) an engineering problem. The business and engineering approaches call for different skill-sets and toolsets which are often not the forté of the typical engineers who tend to drive IPv6 deployment projects.

With the keys to the kingdom (IPv6 deployment has a slot at the resource-allocation table), we now must deal with the second and most challenging hurdle that an organisation will face in actually delivering an IPv6 deployment: failure to execute. In other words, how can we ensure that the deployment project will happen within the stated time-frame and meet its stated objectives in the midst of the 10,000 distractions called ‘The Real Work’? This is not a problem that is unique to IPv6 or IT.

To get an idea of how this problem plays out in real life. Imagine a typical network engineer who sits down in the morning and is faced with two sets of tasks for the day as shown below:

Which one do you suppose they will pay attention to? 99% of the people I’ve posed this question to will focus on the list on the left (the orange one) and for good reason. The tasks on that list are both IMPORTANT and URGENT. Doing those things is what keeps the business running today, money flowing in from clients. Not doing them is what brings down the ire of bosses and quarrel letters and sit-downs with HR and dreadful performance reviews. Unfortunately, being excellent at this won’t bring new capability to an organisation, it just ensures it’s survival. The tasks on the list on the right (the green one) are IMPORTANT BUT NOT URGENT. This list tends to be put off for next week, next month, next quarter or next year until either the organisation chooses to make make it urgent as well (the proactive way) or until business circumstances force them to (the reactive and often expensive way). Initiatives like these are those that bring new capability and the last part of this post is how we can be proactive about making them happen.

Six years ago, I accepted a job as Training Manager at AFRINIC Ltd. After spending time creating a strategy, complete with measures and outlining the various projects and initiatives I’d love to get done (the leadership management part), I got approval for it (the ‘launch’ aspect), then got started on the hard part: actually delivering on those things I’d identified in my strategic plan as being important.

Despite my best efforts and intentions I found that each year, we were only ever able to accomplish about 50% of the new initiatives that management had approved for that year. Turns out that this is one of the biggest problems that organisation face today all around the world. About 87–90% of organisations globally are unable to execute their own strategy. Underneath all the usual culprits of misalignment, lack of motivation, poor leadership and inept management, you’ll find one or more of the reasons 2–5 in the list above. In fact these reasons are common to every strategic initiative that NEVER got implemented to excellence. It’s a perennial problem that many organisations seem resigned to live with.

I stumbled upon what I’ve found to be the best solution to fixing execution failure in the “The 4 Disciplines of Execution” methodology from the folks at FranklinCovey (Do yourself a favour and buy the book). I’m certain that 4DX (combined with Lean Six Sigma process management) can do for organisational productivity what GTD and the 7 Habits of Highly Effective People do for personal productivity. This post is based upon my experience applying both.

An effective execution strategy must address the following problems.

1. FOCUS: How to choose a few priorities (maximum 2 per team) to which a disproportionate amount of the organisation’s energy will be focused. Only by clearly defining this will the IPv6 deployment project stand a chance against the whirlwind of what is considered the ‘real work’. This problem is further exacerbated by misaligned HR policies and incentive systems.
2. LEVERAGE: the deployment team must have some way of knowing week-to-week if they are making progress on a clearly defined goal. Waiting till the end of the year to know how well the team did on “deploy IPv6 across our infrastructure” is not very motivating.
3. ENGAGEMENT: Keeping the deployment team engaged week-by-week on delivering the IPv6 deployment project . No, this isn’t about having off-site parties with ridiculous team-building exercises.
4. ACCOUNTABILITY: Holding EACH individual in the team accountable for doing their bit to deliver the IPv6 deployment project.

Let’s dig deeper in to how the 4DX methodology addresses these issues in an IPv6 deployment project.

Protect IPv6 Deployment from the Tyranny of the ‘Real Work’ – Make It a Wildly Important Goal

I’ve seen organisational (and national) IPv6 deployment projects with goals like “Deploy IPv6”, “Make the government of <insert_country_here> IPv6 enabled”. Such poor problem-definition is at the root of the FOCUS problem. The personal equivalents of such ill-defined goals line walls of The Museum of Stillborn New Year Resolutions e.g. “loose weight” (by how much? when?) or “become better at my job” (as defined by what measure? when?). CLARITY (about what you want to achieve) PRECEDES MASTERY. Clarity the 4DX way is to have all goals for the IPv6 deployment project in the form:

• X is a measure that describes where you are today
• Y is where you want to be
• <date> is the date by which you want to see the transformation

This is called a WIG (wildly important goal)in 4DX jargon. Examples of WIGs for an effective IPv6 deployment would look like:

1. Increase percentage of our IPv6 Internet traffic from 1% to 50% by 31st December 2016
2. Achieve 50:50 distribution in our IPv4 vs IPv6 traffic by 31st December 2017
3. Activate and leave IPv6 on 100% of our public-facing infrastructure and services by 31st December 2016
4. Grow the revenue from IPv6-supported services from $0.00 to $5m per annum by 15th May 2017

Think of the WIG as the war. It is often useful to clarify the minimum number of battles that need to be won in order to win that war. Determining the battles that go with each war(WIG) is best led by the champion together with the senior IT management. Typical battles for an IPv6 war would be:

• Build skills and experience by Doing stuff
• Enabling IPv6 on equipment and services
• Ensuring our vendors are able to supply us IPv6-capable equipment and support them
• Connecting customers
• Resolving IPv6-related problems resulting from deployment

The WIG often needs be broken down further into sub-WIGs that are handled by different departments e.g. a WIG of A"ctivate leave IPv6 on 100% of our public-facing infrastructure and services by 31st December 2016” could be broken down into the following sub-WIGs.

• [Procurement department] Ensure 100% of all RFPs and equipment purchases support IPv6 by 31st December 2016.
• [Training department] Grow the number of engineers who’ve been IPv6 trained from 2% to 60% by 31st December 2015
• [Networking department] Configure and enable IPv6 on 100% of network devices by 30th December

The front-line managers own the sub-WIGs and are responsible for delivering on it. The biggest danger here is misalignment between sub-WIGs and WIGs. Fortunately the 4DX provides a way to ensure this is the case.

Seek and Focus on Lead Measures to Get Leverage

While the WIG is what we are after, achieving them takes time and if that’s the only indication of success, people are going to work for months and not know whether or not they are making progress. The point of leverage is to give the deployment team some short-term (daily, weekly) behaviours or small outcomes and associated indicators that they can focus on. These behaviours (or small outcomes) are chosen such that doing them consistently will ensures progress towards the WIG. In 4DX, these are called Lead Measures. A good lead measure is some action that is a) INFLUENCEABLE: you can do it something about it and b)PREDICTIVE of the lag measure.

Putting it through a personal analogy, You might make a new year resolution to read 12 books this year (a WIG). If that was all you had in terms of measurement, you would only really know if the goal has been achieved at the end of the year. A more effective strategy for achieving that goal would be to read 1 book a month (a sub-WIG) and better still make a habit of reading for 45 minutes every weekday morning (the lead measure). It’s easier to hold yourself accountable to 45 minute reading sessions every weekday morning. It’s a small enough task that is specific enough for you to just do and those 45 minutes every weekday become 10 pages each day, 50 pages a week and 200 pages a month and lo and behold you’re making progress on reading books by focusing not on scary goal 12 books a year, but on 45 minutes of reading every weekday morning.

Here are possible examples of lead measures for IPv6 deployment:

• Number of hours spent per day learning relevant IPv6 skills
• Number of devices/applications IPv6 audited per day/week
• Number of IPv6 related issues in the ticketing system resolved per week
• IPv6 project tasks done per week (assuming there’s already a WBS for the deployment project)

You might think “gosh Tamon, what if we pick the wrong lead measure and waste time on it and it does nothing for our goal?”. Not to worry, the next two disciplines will let you quickly tell if you need to change lead measures. And yes, you will sometimes change or re-define lead measures if they are not moving the lag measure. In order words, if each team member is spending 2 hours per day on IPv6 study (a lead measure) and 5 months later, the % of IPv6 traffic (possible lag measure) still remains the same, then you might need to consider choosing another lead measure like “number of customer CPEs activated for IPv6 per week/day”

Game On!

Now that you’ve solved the problem of focus (with a clearly defined WIG) and leverage (by effective lead measures), you have to solve the age old problem of “how to you keep the (IPv6) deployment team engaged in this project on a weekly basis?”. The answer comes from the one thing that’s almost universally able to keep people engaged: make it a game! Have the IPv6 deployment team create a scoreboard which THEY (not the boss, or the CEO or CTO or champion) update every week. The team records their lead measures on the scoreboard and it enables them to see how they are progressing on their lag measure. The best scoreboards are highly VISUAL and best displayed in a public place where everyone can see it. While the best scoreboards are physical, due to a team that’s not often in the same location, I’ve successfully used a shared Google Sheets as a scoreboard.

Deploy Anti-Slacking Measures

In an ideal world, focus, leverage and engagement would be enough. In the real world, you also need accountability to complete the circle of execution excellence. This in 4DX is achieved by what’s called a WIG session. It is a weekly 20–30 minutes session that goes like this: each person (starting with the boss)

1. Declares what commitments they made last week for the project (“I committed to audit 3 routers in the core network” )
2. States what the status of those commitments are (“I audited 3, 2 of them are good to go and one needs a software upgrade. Full audit report is on the wiki”)
3. Review the scoreboard. Is the Lag Measure moving? (“We are now 67% on completing our infrastructure audit”)
4. Discuss any problems that might have risen during the past week (“I had to skip some devices because I couldn’t run all the audit commands on them while they were live. I’ll have to to those off-peak”)
5. Make new commitments for next week (“next week, I’ll audit all 4 wireless LAN controllers”)

I’ve seen amazing things happen as people look at their scores, compare it themselves to the agreed upon standard and re-commit every week to not being the one that holds the project behind.

Wrapping Up

Nothing happens without appropriate resources. A good champion gets those resources and is and advocate for the IPv6 deployment project on the resource allocation table (the C-suit). You won’t get a good champion without a compelling WHY (a contextualised business case). With the launch underway, if you must,

• have a clear goal for deployment in the format <verb> <subject> from X to Y by <date>
• have 2–4 lead measures that are predictive of IPv6 deployment and influenceable by your team
• create a visual compelling scoreboard that’s updated weekly
• have a 20–30 minute WIG session every week

The more of these items you can check-off, the greater our chances of succeeding at your IPv6 (or indeed any other) deployment project.

You can find the slides to this article on slideshare.