"Even a poor plan is better than no plan at all." - Mikhail Chigorin, chess genius
 

Why use a plan for my Intranet Project?

Not as stupid a question as one might think! After all, the intranet you have at the moment was unlikely to have been planned and probably grew up organically over time.

As a result, it is almost certainly a poor business tool, where the navigation makes little sense and key content and apps are buried away where people can't find them.

More to the point, you are spending some serious money this time around and the result needs to be markedly better than what you had before, or your project will be perceived a failure!
 

What sort of plan do I need, then?

Ideally, you need a phased plan, where the platform is proved first, before a low risk first release. After this, the main priority should be migrating content from the old platform, prior to starting an iterative cycle of rapid development to build critical mass into the new portal.

Subsequent releases

From the end of R1, your steady state support model should have 'kicked in'. At the end of R2, your change cycle should already be in place, with mixed teams of designers, developers and business people working in small teams to deliver iterative, rapid development of key content and new applications.
 

When should my Intranet  project end?

A very pertinent question. In a very real sense, once one has embarked on the iterative release cycle, the only difference between this part of the project and a steady state model is the significant, project-funded resources still available.

One should 'make an end of it' once there is sufficient user adoption of the new portal and sufficient critical mass to ensure that the portal can survive and the benefits case be proven.
 

Intranet Project Products

Each major milestone or release should have associated with it a number of products (or deliverables). For more on this, check out the PRINCE2 materials and also the development section.

Proving the platform (R0)

Most Portal software permits one to get a portal 'up and running' in 2-4 weeks. You should take advantage of this and start with a pilot (release 0). This allows you to prove the platform works within your infrastructure and to test your approach to design and navigation. Use a 'safe' community (perhaps the project team itself) to evaluate the approach against your strategy and a set of quality criteria.
 

The first release (R1)

Early in the first release, you will need to complete your detailed design for the portal (based on learning from the pilot). A low risk first release with a pioneer community is advisable, in order to test the enterprise applications (e.g. Content Management System and White/Yellow Pages applications) prior to full roll-out.
 

The second release (R2)

There are two themes to R2; firstly the scaling-up of the platform to the full user base and, secondly, the migration of content from the old intranet to the new portal. As far as possible, one should train content managers early, so they can assist with migration of their own content.