It often happens during one my IPv6 training courses that a participant comes up and asks (or puts it as something that was missing from the training) – “What are the specific steps for deploying IPv6?”. This often leaves me puzzled as I assume any engineer will have a framework for achieving technical projects. Then it occurred to me that not all engineers have project management experience or knowledge, hence this post.

Well the answer is that to deploy IPv6 right, you take the same project-based approach you’ll take for any project, which put simply goes like this:

1. Define clearly what you want to achieve – the goals.
2. Identify the list of tasks you will need to achieve each goal.
3. For each task, identify what resources you will need – people, finances and time
4. Get management sign-off/approval for the project
5. Start executing the project – aka Deploying IPv6
6. Document the project and lessons learnt.

This is a simple framework I believe anyone can follow and deliver an effective IPv6 deployment for their organisation. In the world of all effective people, frameworks and plans are everything. So let’s review each of the steps.

[A] Set Clear Goals for the IPv6 Deployment Project

If you don’t know where you are going, how are you going to know it when you arrive? This stage is the most important task you need to perform as the success or failure of the entire IPv6 deployment depends on it. I’d recommend having very clear and specific goals like:

• Have our public facing Internet services available on IPv6 by December 2013
• Be able to provide dual stack (IPv4 & IPv6) services to customers by May 2014
• Ensure that all our internal users can access the Internet over IPv6 by end December 2013
• Roll out our LTE service exclusively on IPv6 by end of Q2 2014.

Notice two things present in each of these goals – they are Measurable and Time-based. (They are also SMART – but as you must have guessed, I think SAR are overrated.)

Your initial goal might possibly be just a first iteration, and as you plan the project, you might need to clarify it more. To highlight the importance of this step, in November 2012, Andrew Alston reported an interesting issue with Yahoo IPv6 access for South African users; while there was IPv6 connectivity and AAAA DNS resource records, the services themselves were NOT configured to serve content over IPv6! And that being the case users would not get failover to IPv4 even if though the server was perfectly capable of serving its content over IPv4.

That looks to me like poor goal-setting on the part of a project manager or coordinator. Yes it’s the whole “Begin with the end in mind” thing and it is still a great principle for doing anything right – IPv6 Deployment included. A goal of “Configure IPv6 addresses on the web server and create AAAA records in DNS for our website” will strictly yield a different result from “Ensure that our website is fully accessible directly and natively over IPv6″.

[B] Identify the List of Tasks Required to Achieve each Goal

Here you pick each goal and ask yourself – “what tasks must we accomplish in order to achieve this goal?” In project management terms, this is called progressive elaboration and the result is that you will end up with a list of tasks that must be done to achieve the goal – the Work Breakdown Structure so to speak. For example, take a stated goal like :

G.1 Ensure that our web servers are accessible over IPv6 by May 2013. This can be progressively elaborated as follows:

1. Perform audit of the web server infrastructure to ensure it can support IPv6.
2. Address any recommendations from the audit above.
3. Review security policy relating to the web services and update to cover IPv6.
4. Create AAAA records in DNS infrastructure for the web server.
5. Configure IPv6 addresses on the web server.
6. Configure IPv6 addresses on load balancers (if applicable).
7. Configure the web server software to accept and server requests over IPv6.
8. Establish a test plan for this deliverable.
9. Test the web server against the test plan.
10. Launch the service.
11. Update all relevant documentation.

Each of these is a task that will take specific inputs, be allocated specific resources (time, equipment, people etc) and deliver specific outputs. It is the combination of these outputs that will determine whether the goal has been achieved. Some of these tasks are are interdependent and so one will depend on one finishing before they can start. Other of the tasks are independent and can be assigned to different resources and started concurrently. The project manager will have to analyse these tasks to find out any inter-dependencies so as to be able to optimise how the tasks and resources are allocated and executed. The tools and techniques of PERT, CPM and Critical Path are quite useful here, Critical Path being the most effective.

[C] Identify Resources Required to Accomplish each Task

This part is a lot easier once you’ve clearly specified and elaborated the goals. Starting with each of the tasks associated for each goal, list the resources you will require. Here again, you might want for each task to look at resources required in this framework:

Skills: what specific skills are required to perform this task. Knowing what skills are required, will point to what people in the organisation have those skills and would thus be resources on the IPv6 Deployment project. Think through this right and you just might have better luck that this project manager.

Getting project resources

Time: how much time can reasonably be expected to be spent on this. These are just estimates. Beware of the traditional problem of PERT scheduling though.

Equipment & Software: Some tasks might require specific equipment for their accomplishment, list them here.

Money: Need I say more? …

A project coordinator or manager who is non-technical may not know the exact details of these requirements, but that’s where they go talk to consultants, existing technical leaders in the organisation or do research, including mailing lists.

I can’t stress enough the importance of doing due diligence here. One of the complaints I hear from executives is “my techies want this cool new thing but they can’t tell me exactly how much in terms of resources, man-hours and money this will cost us, what (if any) are the risks, their impact and how we will mitigate those risks”.  If this is done right (and then taken further by identifying some ways to cut costs by re-using existing resources), then the business executives are going to be more impressed and it helps greatly in the next stage — getting management approval and sign-off.

[D] Get Management Approval/Sign-off for the Project

If you did steps [A] to [C], congratulations, you now have a project brief that management can look at and more importantly sign off on. Rather than dump a long document on them, you might want to schedule a meeting and do a presentation to the management team or better still the decision makers. In your presentation you’ll give them the short version which essentially says something like:

“Our organisation needs to deploy IPv6 for the following reasons (list the reasons). The benefits to us are (list the benefits). In order to do that we need to do (list the key high level goals that must be achieved). There are risks involved (list risks and their impacts) but here is how we will mitigate those risks. We will need the following resources  and it will take X amount of time and cost $dollars”

Even if management asked for it, you still need to get their buy-in and sign-off on your project proposal because that is what will open the tap to resource allocation process so that you may get the resources you need to move on to a successful implementation.

Well as an effective project coordinator or manager, you need to “pre-wire” the meeting where you present the project proposal. In order words, you need to identify key stakeholders, their influence and how much of their support you need and first approach them and share your plan with them, collect their feedback. If you do that, then your actually presentation/meeting will be short and fruitfully because there will be no ‘surprises’ (something which I have found many managers and ‘bosses’ feel mortally threatened by).

If you did a great pre-wiring job, then you’ll walk out with sign-off of your proposal, if not, then you might well get some feedback (essentially management saying we cannot give sign-off until certain aspects are reviewed). In any case you if there objections/concerns, you will have to address them and repeat till you get sign-off on the project proposal.

[E] Execute the Plan, Documenting Everything as you go

Congratulations! Armed with a management-approved deployment plan, now the real work starts. Getting down to actually DOing the work of deploying IPv6 in your organisation. Simply put, you’ll now engage whatever collaborative tools and processes your organisation has for doing projects to get the work of the project done. If your organisation has a project management office or has some official project management methodology they use (PRINCE2, PERT, Critical Chain etc) be sure to use it so as to benefit from hopefully in-grained organisational processes and the culture.

Ultimately, you’ll review the work breakdown structure, have meetings with various people involved to clarify deliverables, put the project milestones and tasks up on the company project management software (you are using one rather than email right?) and assign them to various people, follow up with various units for other resources and make sure things run on schedule – adapting as the project progresses.

Don’t forget to keep communications flowing amongst the various stakeholders, these updates include but are not limited to:

• Follow up communications to people that have tasks that are about to start, are overdue or that have changed.
• Status updates to project champions in the management team to keep them in the loop and make sure they can continue drumming support at the executive level.
• Regular updates to the entire organisation to know when key milestones have been achieved.
• etc etc

It is also great to make ‘documentation’ a mandatory part of the accomplishment of each task or work unit. That way there’ll be sufficient low level documentation from which the project manager, coordinator or editor can collage accurate global documentation for the project.

[F] Update Relevant Organisational Processes to Integrate new Capabilities Resulting from the Deployment

So you have now deployed IPv6 on your infrastructure and services and everything has been tested and works like charm. Congratulations …but you are not yet finished. What you’ve done till now is deliver a new service or set of capabilities. This must be integrated into the organisation’s business model for the organisation to derive any value from it. It means some or all or more of the following tasks must be done:

• Train the marketing and sales staff on the implications of IPv6 -and yes, help them integrate IPv6-capability into their marketing and sales literature and messages.
• Train the support staff in the necessary skills required to deal with customer problems that are IPv6-related.
• Review and updated any organisation processes that have changed as a result of the new deployment.

While not an exhaustive step by step guide, I am confident that anyone that adopts such a framework and clear goal-oriented approach to be able to deliver an IPv6 deployment project in a professional and effective manner.

Have you been part of an IPv6 deployment project lately? Please share you perspectives in the comments section.