INFO 638 Assignment #2 Estimation and Scheduling

Due date for this assignment is on the syllabus.

As usual, there are no specific page limits. There is a group part and an individual component to this
assignment. This assignment is to continue the project used for Assignment 1.
1. Refine the WBS based on instructor feedback. Break each activity down and write a brief
scenario for each one, based on the example below. Use the WBS example as an example of the
types of thing that should be in a WBS (also see the examples on the book CD-ROM). But do not
follow this slavishly think about your own project circumstances.
2. Produce an activity-scenario for each WBS activity (see below for activity-scenario definition
we are producing these instead of the more detailed WPDs (Work Package Descriptions, which
you are not expected to provide) defined in Ch 7 of the book. The term activity, as used here,
describes a sequence of smaller steps or tasks with an identifiable goal e.g. deliver a tested
system.
3. Estimate the duration of each project activity or task and determine their sequence. Document the
method used for estimation (i.e. show your work).
4. Prepare a short financial analysis of your project. Produce a cost-benefit statement that allocates
costs to the various WBS activities, as ballpark figures, and provide the basis for your figures
(e.g. 30 man-hours @ $35/hour * 1.35 overhead attribution). My figures are taken out of thin air,
so please do not use these Id like you to research what figures are used by local companies
and use their typical methods of costing projects.
5. Present the schedule as a report, with a discussion of the project timescales, critical activities,
feasibility, and financial viability, from the above analyses (put detailed analyses in a separate
appendix for each). Present graphic versions of the schedule, either as a Gantt chart or
PERT/CPM chart. (I prefer using a Gantt chart as it is easier to spot timescale errors, but this is
your choice).
o Make sure to integrate the charts into the same Word document as the rest of the
assignment. See MS Project tips in the syllabus.
o If the Gantt chart gets too big and complicated, show the top level WBS on one chart, and
show separate charts for each activity-breakdown. So the WBS chart is a summary of the
entire project, and the WPDs expand on the lowest level WBS tasks to show more detail
below that. You can collapse tasks to the highest level task in MS-Project, to print
different task levels or subsets.

What To Plan For The WBS

Most of the project failures that I have seen occurred for two reasons:
(a) the Project Manager did not understand how to evaluate progress towards an activity-goal (or did not
understand what success meant for a WBS activity), so tasks slipped or system requirements failed
to be understood;
(b) The Project Manager failed to plan for the organizational and business process changes associated
with the system introduction. Youre an idiot if you dont understand what else needs to change,
besides the technical system introduction. Training does not even begin to describe the workprocess changes, information access and sharing changes, and work-task evaluation changes that
accompany system change. When you get a more major systems change (i.e. a new system to support
a different way of performing, evaluating, or coordinating a business process), you also have different
people performing different work. An information system does not magically make new work
processes happen effectively. You need to run pre- and post-implementation process training
workshops, to make sure that everyone understands what is required for the new process to work. The
earlier you run the first set of pre-implementation workshops, the more likely you are to identify
system requirements that you did not know you had! If you can produce some sort of prototype for
the pre-implementation process workshops, you can reduce your risk of system failure appreciably.

Why WBS vs WPD?

The reason for the WBS versus WPD structures makes more sense for a really large project. Imagine
there is a team of managers and top analysts that collaborate to prepare the WBS, and define the time and
effort limits for each major set of tasks in it. Then they hand off the lowest level tasks of the WBS to each
WPD manager to figure out what specifically will be done in it. So the system architect might be given
task 2.1 above, with a budget of X people hours and Y months, and they have to define the detailed WPD
tasks that will fulfill the overall purpose of task 2.1. As the main function of WPDs is to allow a Project
Manager to control and coordinate subcontractors or subgroup-managers who are filling in the detail of
the project plan, WPDs are not required for this project. When the same group of people is both defining
the requirements and implementing the system, WPDs tend not to be used, as everyone understands what
needs to be done for each activity.

Activity-Scenarios For WBS Activities

A activity-scenario provides a mental walk-through the activity, so that you can anticipate risks and
understand task-coordination and user-involvement issues across and within activities. They can be very
short for simple activities and longer for more complex activities. A scenario should include:
1. A (brief) descriptive walkthrough of what needs to be done, to complete the activity.
2. A list of human and other resources required, with mention of unusual skillsets.
3. A (brief) description of how the activity outcomes will be evaluated, with evaluation criteria.
4. A discussion of potential risks identified with the activity, together with a strategy for managing each
risk.

Tips

In developing activity scenarios, use job titles for each human resource role, like Chief Architect
or Testing Manager, not fake names like Mick E Mouse or Bart Simpson. Though not explicitly
required until assignment 3, you are implying parts of your projects organizational structure
through the roles you define here, so use a consistent set of job titles.
Try to think beyond just the technical tasks of developing your system. WBS and activityscenario tasks may include performing some action for different parts of your system (like the
server vs. client tasks in the sample WBS), or developing documents to capture the results of the
WPD, or getting approval of the work performed, or meeting with your customer, or conducting
training, process-walkthrough workshops, etc. with managers and system users. They may also
include system prototype evaluation, or joint application design workshops (collaborative
requirements definition and validation workshops with user or client representatives these can
run for half to 1 day regularly over several weeks, to clarify requirements in specific areas of
system use).
Try to balance the scope of the WBS activities to be vaguely similar, especially if they are to run
in parallel. If at all possible (and it is not always possible), dont have one WBS activity be 1000
hours of work, and another 50 hours.
Its possible to combine related top level WBS tasks in an activity-scenario in the above
example, integration and system testing might be relatively small tasks (in terms of effort), and
the same manager might be responsible for planning both of them, so they could be part of one
activity-scenario for a small project.
Activity or task names in the WBS or activity-scenarios should start with a verb, and end with a
noun, like the examples above. Make sure both noun and verb are present, so Release and Web
client are incomplete task names, because I cant tell what youre releasing, or what youre doing
to the poor innocent web client.