"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
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