|
ID
|
Task Name
|
Duration
|
Notes
|
WBS
|
| 1 |
|
0 days |
1) This plan is not resource
loaded. For example, Tasks 3, 4, and 5 all have
predecessor 2. They can be done simultaneously
if the resources are there to do it; if not they
will have finish-to-start dependencies and will
stagger accordingly.
2) Durations are only approximate elapsed
time! Durations will vary according to the size
of the project team, scope of the task,
3) There is no risk accounted for in this
template. Although we have added a 'Define risks
and risk management approach' task in the
concept phase, contingencies according to the
perceived risk of the task should be added to
the durations.
|
1 |
| 2 |
Concept |
18
days |
|
2 |
| 3 |
Evaluate
current systems |
5 days |
Evaluate how your company's
current system of communication works (e-mail,
public folders, network servers) and determine
how you will migrate/integrate that system into
an intranet site. |
2.1 |
| 4 |
Define
Requirements |
5 days |
|
2.2 |
| 5 |
Define
user requirements |
5 days |
Some examples of questions
that should be asked when defining user
requirements are:
What is the business problem being addressed
by this project?
Who are the users and what are there specific
needs (example: developers looking for code,
graphic designers looking for cool web ideas)?
What will users gain as a result of this
project?
|
2.2.1 |
| 6 |
Define
content requirements |
3 days |
Decide what information
users require and how they prefer to access that
information. Determine exactly what content will
move to the intranet and for which user types. |
2.2.2 |
| 7 |
Define
system requirements |
3 days |
Some examples of questions
that should be asked when defining system
requirements are:
1) What operating systems will the project
support?
Different systems behave in drastically
different ways and can have a massive impact on
your project.
2) What browser are you targeting?
3) Will you publish a CD-ROM version of the
site?
If you know this in advance, you can do
things up front which make it easier to transfer
site content.
4) Will you support 16 bit, non-longfilename
systems?
If you have a v-root with a long filename,
you will have real trouble replicating that
content to CD-ROM and using it on systems that
do not support long-filenames.
|
2.2.3 |
| 8 |
Define
server owner requirements |
2 days |
Your organization may have
strict rules about how information is stored on
their machines. Some of the questions that
should be asked when defining server owner
requirements are:
1) Who is your contact in IS?
2) Is there any specific HTML formatting
requirements (fully qualified paths, relative
pathing, weblint)?
3) How much time do they need to post
material?
4) If the site has problem, who, how, and
when can you contact?
5) If you are performing advanced
engineering, what are the requirements (no CGI,
SQL Server, Custom DLLs, ActiveServer
technology, RealAudio)?
|
2.2.4 |
| 9 |
Define
specific functionality |
1 day |
Take the user requirements
and put them in terms of functions for the
developers. Examples:\
The users need to be able to give feedback to
the owners of the content directly from the web
site.
There may be a need for a sophisticated
search engine.
The users want the site to be fast, so that
means that developers should not put many
graphics on the pages.
The users may want access to another already
existing database, such as a headcount database.
It may be necessary to create a CD from the
intranet content.
Note: This task is where the function (for
example, direct feedback) is determined; the way
that function will be implemented (by email? by
direct feed into a database?) will be determined
during the "Design User Interface"
task.
|
2.3 |
| 10 |
Define
risks and risk management approach |
4 days |
It is important to analyze
your concept, the environment you are working
in, and the potential problems that could arise.
These areas of risk should be documented and a
plan formulated to mitigate the risk where
possible, and to manage the risk where
necessary. Depending on the degree of risk
inherent in the project, you may want to add
contingencies to the durations in this project
plan. |
2.4 |
| 11 |
Develop
project plan |
2 days |
Bring all of the necessary
information together in a plan. The plan should:
1) State the business objective and summary
strategy.
2) Detail user content and functionality
requirements.
3) Define the top level tactics and the
timeline.
4) Identify owners of each implementation
group (e.g. development, editors, testers)
|
2.5 |
| 12 |
Brief
web development team |
1 day |
The project plan will be
used as a tool to communicate with the
development team whether they are an internal
development team or an external vendor. As a
result of the briefing you should have committed
development resources for the project and buy in
on the project timeline. |
2.6 |
| 13 |
Web
Site Design |
22
days |
|
3 |
| 14 |
Design
User Interface |
12 days |
|
3.1 |
| 15 |
Determine
the layout of the site |
8 days |
Figure out conceptually what
you want the look and feel of the site to be. If
the site is large you will want to absolutely
determine the design and layout of the site. If
you don't decide, and have builders work on HTML
and navigation, you will spend about twice as
much time going back over everything and redoing
the HTML to make the design revisions. Design
should be decided on first and agreed on by all
parties. |
3.1.1 |
| 16 |
Determine
the data links |
4 days |
Determining conceptually
what your "hot spots" will be and what
they will link to. |
3.1.2 |
| 17 |
Decide
how to implement functionality |
3 days |
After you have defined the
specific functionality in the Concept phase, you
must decide how to implement it. This decision
entails whether you will have in-house
developers do the work, hire vendor development
services, or will you buy a product off-the
shelf to implement the functionality.
For example, functionality important to the
users may be the ability to give feedback
directly from the web site to the content
owners. This can be done by implementing a link
that sends email to the content owners, or by
creating a page that puts the feedback into a
database. Creating a hot link to email needs
very little development, but there must be a
scheme set up to maintain who that mail goes to.
Creating the direct-feedback page takes more
development, but you have greater control over
how the feedback is formulated and can be
reported on. These types of tradeoffs need to be
considered when designing functionality. In this
stage you need to perform some cost-benefit
analysis as to whether it is more beneficial to
develop the function in-house, hire vendor
development services, or buy the function in the
form of a off-the-shelf product.
|
3.1.3 |
| 18 |
User
Interface designed |
0 days |
|
3.1.4 |
| 19 |
Design
Server Setup |
6 days |
|
3.2 |
| 20 |
Determine
estimated disk space utilization |
0.5 days |
Determine how much data you
will have so that you know how much space it
will take up on the server. |
3.2.1 |
| 21 |
Determine
estimated traffic |
0.5 days |
How many people will visit
your site and how often will they visit it? This
will help you figure out what server (hardware
and software configuration) you should use. |
3.2.2 |
| 22 |
Design
access permission |
1 day |
This task involves deciding
who has access to what information on the
intranet. IIS (Internet Information Server) on
the NT server helps you do this very easily. |
3.2.3 |
| 23 |
Design
testing/staging area scheme |
3 days |
Since you do not want to
make content changes to your intranet while
users are working on it, you need to define how
changes to content will be made and how those
changes will be propagated to the live site. |
3.2.4 |
| 24 |
Communicate
with server operations |
2 days |
Communicate all server
requirements with personnel responsible for
server operations so that they can prepare and
set up the production server.... |
3.2.5 |
| 25 |
Server
site live |
0 days |
|
3.2.6 |
| 26 |
Develop
Server Support Infrastructure |
6 days |
|
3.3 |
| 27 |
Determine
network impact |
2 days |
Ideally, a lab should be set
up to simulate the production network (bandwidth
and traffic). Since this is not always feasible,
your best guess on impact to the network is
important so that different potential solutions
to problems can be identified. |
3.3.1 |
| 28 |
Determine
what changes need to be made |
3 days |
If your system's speed,
reliability, or response time will be
compromised because of network issues, you must
determine what steps need to be taken to address
those issues.
For instance, if response time at a remote
site in a different part of the world will be
intolerably slow, you may need to replicate the
web site on your server to a server local to
that site.
|
3.3.2 |
| 29 |
Communicate
with support staff |
1 day |
Keep your support personnel
abreast of any issues you think relevant
(network, server, or content related), so that
they can prepare to staff accordingly. This is
important because you want your support staff
and intranet site to go live simultaneously. |
3.3.3 |
| 30 |
Support
requirements met |
0 days |
|
3.3.4 |
| 31 |
Web
Site Development |
55
days |
|
4 |
| 32 |
Develop
pages and links |
18 days |
This is the stage in which
you create the HTML source code. If you do not
have developers assigned to this task, Microsoft
FrontPage, Internet Assistant for Word, and
other HTML editors can perform this function
quickly and easily. |
4.1 |
| 33 |
Create
HTML style 'template' |
3 days |
If development is being done
in-house, it is useful to have certain standards
followed for HTML coding. This makes the code
easier to maintain in the long run. Creating a
template for your developers will help this
effort. |
4.1.1 |
| 34 |
Determine
development tool |
1 day |
Will you use an
off-the-shelf HTML editor? Or create your pages
free-form? Or will you customize a
data-conversion tool if you are converting an
existing system? All options need to be
considered. |
4.1.2 |
| 35 |
Development |
15 days |
The size of this task
depends on the amount of content your web site
will contain. The more detailed design work done
up front, the quicker this task will be
accomplished. |
4.1.3 |
| 36 |
Develop
functionality |
22 days |
After you have designed the
functionality, you must develop it or buy it,
depending on the cost-benefit analysis performed
in the design phase. |
4.2 |
| 37 |
Develop
any custom functionality |
15 days |
If custom development is the
way you want to proceed with getting the
functionality you need, determine who will be
responsible and plug them into this task. |
4.2.1 |
| 38 |
Integrate
into web site |
4 days |
Once the functionality you
need for your web site is complete, either by
your own development or by purchasing some 3rd
party software, integrate it into the other
pages to complete the site. |
4.2.2 |
| 39 |
Content
Migration/Integration |
27 days |
|
4.3 |
| 40 |
Determine
what content will be moved/converted |
3 days |
Define what specific content
will be converted to HTML to be viewed directly
on the site and which content will remain in its
native file form and linked to from the
intranet. Determine the source and location of
each type of content. |
4.3.1 |
| 41 |
Prioritise
content conversion |
2 days |
Create a content site map
detailing where each content type resides today
and where it will reside on the new web server.
Prioritise the content migration, i.e. determine
in what order the content will be moved to the
web and, if appropriate, what content will be
archived. |
4.3.2 |
| 42 |
Set
content conversion standards |
2 days |
Define how you want the
content to appear on each page.
1) Determine what color the links should be
before and after they have been used.
2) Determine the color and size of headings
and other fonts.
3) Determine the standard placement of
graphics etc.
|
4.3.3 |
| 43 |
Implement
content migration and conversion |
15 days |
Convert necessary content to
HTML either manually or by utilizing a set of
conversion utilities. The choice is dependent
upon the quantity of content that requires
conversion. Your development team can advise you
on the type and availability of conversion
utilities. |
4.3.4 |
| 44 |
Test
conversion formats |
5 days |
Once the content has been
converted either manually or with the aid of
conversion utilities, an editor should double
check the quality of conversion to make sure
that standard formats are in place. |
4.3.5 |
| 45 |
Testing |
23 days |
|
4.4 |
| 46 |
Create
test plan |
4 days |
Define your overall test
plan - including when, how, and roles and
responsibilities of the parties involved. |
4.4.1 |
| 47 |
Page
Testing |
10 days |
Test the individual pages. |
4.4.2 |
| 48 |
Link
Testing |
6 days |
Test the links/connections
of all pages of the site. |
4.4.3 |
| 49 |
Usability
testing |
8 days |
For this stage of testing,
you have the users use the site and test to see
if it meets the requirements that we had defined
in the concept phase. |
4.4.4 |
| 50 |
Stress
testing |
8 days |
Simulate the load on the
system to test the performance of the site
according to the predetermined requirements. |
4.4.5 |
| 51 |
Roll
Out |
25
days |
|
5 |
| 52 |
Move
site to production server |
2 days |
Move the site to the server
that users will use when the site goes live if
it is not already there. Do this step before
stress testing if you do not have a way to
simulate the production server. |
5.1 |
| 53 |
Determine
roll out schedule |
5 days |
Determine the order in which
groups or users within a group will go live on
the system. A staggered roll out will allow
trainers and support staff to spend more time
with individual users. |
5.2 |
| 54 |
Communicate
roll out plan to users |
10 days |
All users at all locations
should receive a detailed plan for the roll out
informing them when the roll out will occur and
when and where training is available. |
5.3 |
| 55 |
Conduct
user training |
10 days |
Even in very small groups,
users should go through a formal training course
on the new system. Formal training will reduce
support calls and user frustration. |
5.4 |
| 56 |
Release
internal PR |
10 days |
To generate internal
interest for the new web site it is useful to
conduct internal PR announcing the new web site
location and live date. |
5.5 |
| 57 |
Rollout |
0 days |
{The roll out day is the day
the site formally goes live and is available for
all users to access.
Extra time has been added to the duration of
this task to help account for any unforeseen
problems that may arise.
|
5.6 |
| 58 |
Support |
28
days |
|
6 |
| 59 |
Determine
what support resources are needed |
4 days |
Determine what and how many
support resources are needed to effectively
support the users that will be using the
intranet site. |
6.1 |
| 60 |
Make
appropriate staffing changes |
5 days |
If you determined that more
support resources are needed than you have
available, make the appropriate staffing
changes. |
6.2 |
| 61 |
Determine
method that users will attain support |
3 days |
Decide whether you will use
a Help Desk, a hotline, email, etc. |
6.3 |
| 62 |
Determine
support process |
5 days |
Decide how support will be
administered: maximum time until help is
delivered, if and how calls will be logged, etc. |
6.4 |
| 63 |
Support
goes live |
0 days |
This should occur
simultaneously with the rollout of the site. |
6.5 |
GENERIC INTRANET PROJECT PLAN