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:
- Define clearly what you want to achieve – the goals.
- Identify the list of tasks you will need to achieve each goal.
- For each task, identify what resources you will need – people, finances and time
- Get management sign-off/approval for the project
- Start executing the project – aka Deploying IPv6
- 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:
- Perform audit of the web server infrastructure to ensure it can support IPv6.
- Address any recommendations from the audit above.
- Review security policy relating to the web services and update to cover IPv6.
- Create AAAA records in DNS infrastructure for the web server.
- Configure IPv6 addresses on the web server.
- Configure IPv6 addresses on load balancers (if applicable).
- Configure the web server software to accept and server requests over IPv6.
- Establish a test plan for this deliverable.
- Test the web server against the test plan.
- Launch the service.
- 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
[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:
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
Getting project resources
how much time can reasonably be expected to be spent on this. These are
just estimates. Beware of the traditional problem of PERT scheduling
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
“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
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
- 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.