Archive for the ‘Planning’ Category

When to Perform Pre-Implementation Planning (3rd in a Series of 3)

Posted January 20, 2009
Filed under: Implementation/Integration, Planning | Tags: , , ,
* Leave a comment

Here is the previous portion of this particular post.

In the first two parts of this post, I spoke about the “what” and the “who” of implementation planning.   Specifically I talked about pre-implementation checklists and pre-implementation conference calls.  I also talked about getting buy in from senior management and taking a top down approach towards planning.

Now I tackle the question of when to preform preimplementation planning.  While it is mostly common sense, my answer is “not too soon, and not too late”.  I believe the sweet spot is usually 1-2 weeks before the beginning of the project.   For longer projects with more detail, it may be neccessary to begin planning even sooner.  For short projects (less than a week), pre-implementation planning may be done 2-3 days before the official start of the project.  At that time, an official kickoff meeting may be required.  We will explore the timing, audience, and agenda of kickoff meetings in a future post.

Advertisement

Who to Include in Pre-Implementation Planning (2nd in a Series of 3)

Posted January 15, 2009
Filed under: Implementation/Integration, Planning | Tags: , , , ,
* Leave a comment

Read the first part of this post if you haven’t already.

In the first part, I talked about pre-implementation conference calls and pre-implementation checklists as planning tools that ensure a smooth deployment of a new technology.

One area that I didn’t discuss was who to involve in these processes.  Because we are talking about a change – either in the form of implementing a new technology or in the form of upgrading an existing one – it is best to have senior management involved.    Any business book on change or change management is likely to tell you the same thing.

*Why* is it important to get these individuals involved?  I believe two main reasons.   First, a top-down approach ensures that individuals with the proper authority make (or approve) decisions.  If decisions are made by those with no authority, large amounts of re-work become a credible threat to the project as original decisions may be overruled.   You also can’t make much progress if there is no one involved in the planning process who is willing and able to make decisions.

Second, besides having authority, most leaders are decisive.  This makes project planning more efficient because they are able to quickly settle any disputes around network architecture and design.   As the old saying goes, “there’s more than one way to skin a cat”.  I also think this is applicable to network architectures – there are often many different ways to design a network to meet the business and technical requirements at hand.   Having senior management involved can eliminate the often spirited debates that arise on which design is best.

What to Include in Pre-Implementation Planning (1st in a Series of 3)

Posted January 12, 2009
Filed under: Implementation/Integration, Planning | Tags: , , , , , ,
* Comments (1)

I am starting a large district wide implementation of our Xirrus arrays.  This particular deployment is 150+ arrays.  For those of you who are unfamiliar with Xirrus, we aggregate from 4-24 radios (we call them integrated access points) in every device along with a non-blocking Layer 2 switch, WLAN controller, integrated threat sensor and spectrum analyzer.  Our integrated access points utilize directional antennas, which allow us to cover more area using 75% less devices than our competitors.

This is helpful to understand the scope of the project.  While we have 150+ arrays, the competing bids were for approximately 600 access points.   It is certainly not the largest WLAN rollout I have worked on, but larger than most.  My question today is “How do you plan/prepare for large deployments of new technology?”

My personal philosophy goes back to an adage that my father taught me, which was “Measure twice.  Cut once.” There are certain processes that I have used over the years.  These include both a pre-implementation call and a pre-implementation checklist.

The pre-implementation call seems more useful when I have not been involved in the sales effort and the project is being passed to me as an engineer for integration into the customer’s network.  Normally, the sales team, project manager, and implementation team get on the phone to restate the technical and business requirements of the project to ensure everyone is on the same page.  In my opinion, one of the frequently overlooked areas on this type of phone call is a definition of the project’s success criteria.

The pre-implementation checklist has been more useful to me in situations where I have been a part of the sales cycle and know the account history and requirements. What I am looking for then are the technical details – the IP addressing scheme, the naming convention, the authentication methods, the encryption schemes, etc.

I have used several different forms and versions of pre-implementation checklists.  What format do you prefer – Excel Spreadsheets or Word documents?  Ones with a higher number of detailed questions or ones with a few number of high level questions?  What area(s) do you think are often missed during the planning stage of a new project?