5. Managerial process plans
5.1 Start-up plan
5.1.1 Estimation plan
This subclause of the SPMP shall specify the cost and schedule for conducting the
project as well as methods, tools, and techniques used to estimate project cost,
schedule, resource requirements, and associated confidence levels. In addition, the
basis of estimation shall be specified to include techniques such as analogy, rule of
thumb, or local history and the sources of data. This subclause shall also specify the
methods, tools, and techniques that will be used to periodically re-estimate the cost,
schedule, and resources needed to complete the project. Re-estimation may be done on
a monthly basis and aperiodically as necessary.
See PMP from Microsoft Project for estimation schedule (will copy and paste once ok’d
and verified).
Microsoft Project is the tool being employed to create an estimated schedule as well as
track resource requirements and project completion. There will be no costs associated with this
project. This project plan will be reevaluated as work progresses and adjustments will be made
as necessary during each iteration to account for any changes in the schedule.
5.1.2 Staffing plan
This subclause of the SPMP shall specify the number of staff required by skill level, the
project phases in which the numbers of personnel and types of skills are needed, and
the duration of need. In addition, this subclause shall specify the sources of staff
personnel; for example by internal transfer, new hire, or contracted. Resource Gantt
charts, resource histograms, spreadsheets, and tables may be used to depict the
staffing plan by skill level, by project phase, and by aggregations of skill levels and
project phases.
See PMP from Microsoft Project for the staffing plan (will copy and paste once ok’d and
verified).
5.1.3 Resources acquisition plan
This subclause of the SPMP shall specify the plan for acquiring the resources in addition
to personnel needed to successfully complete the project. The resource acquisition plan
should include a description of the resource acquisition process, including assignment of
responsibility for all aspects of resource acquisition. The plan should include, but not be
limited to, acquisition plans for equipment, computer hardware and software, training,
service contracts, transportation, facilities, and administrative and janitorial services. The
plan should specify the points in the project schedule when the various acquisition
activities will be required. Constraints on acquiring the necessary resources shall be
specified. This subclause may be expanded into additional subclauses of the form
5.1.3.x to accommodate acquisition plans for various types of resources to be acquired.
No additional resources will need to be acquired in addition to personnel.
5.1.4 Project staff training plan
This subclause of the SPMP shall specify the training needed to ensure that necessary
skill levels in sufficient numbers are available to successfully conduct the software
project. The training schedule shall include the types of training to be provided, numbers
of personnel to be trained, entry and exit criteria for training, and the training method; for
example, lectures, consultations, mentoring, or computer-assisted training. The training
plan should include training as needed in both technical and managerial skills.
No additional staff training will be necessary to complete this project.
5.2 Work plan
See PMP from Microsoft Project for work plan (will copy and paste once ok’d and
verified).
5.2.1 Work activities
This subclause of the SPMP shall specify the various work activities to be performed in
the software project. A work breakdown structure shall be used to depict the work
activities and the relationships among work activities. Work activities should be
decomposed to a level that exposes all project risk factors and allows accurate estimate
of resource requirements and schedule duration for each work activity. Work packages
should be used to specify, for each work activity, factors such as the necessary
resources, estimated duration, work products to be produced, acceptance criteria for the
work products, and predecessor and successor work activities. The level of
decomposition for different work activities in the work breakdown structure may be
different depending on factors such as the quality of the requirements, familiarity of the
work, and novelty of the technology to be used.
To execute the Iterative and Incremental GDD Process, we decided that each team member
would be responsible for a specific phase and at the end of each iteration we would have a working
prototype. Kevin would gather the requirements, Adriana would do the design, Haroon would do the
implementation, Ahmed would do the testing and maintenance. We feel that this particular process
best fits the project requirements by offering an iterative approach that is not overly complicated. We
can move between phases with each iteration of the project taking between 1 to 2 weeks (or as
necessary) for completion. Because of the limited time frame we are on, we have to compress a
number of elements that ordinarily may take a week or longer. We anticipate that the requirements
phase of each iteration will take 3 to 4 days as we analyze and either accept or reject requests as well as
implement older project ideas. The design phase where we tweak design characteristics and create
mockups will take up to 2 days. The coding phase will occupy another day or two. Depending where we
are in the project, the testing phase will occupy a greater amount of time. This is to allow for thorough
testing of the application as it is closer final product.
5.2.2 Schedule allocation
This subclause of the SPMP shall provide scheduling relationships among work activities
in a manner that depicts the time-sequencing constraints and illustrates opportunities for
concurrent work activities. Any constraints on scheduling of particular work activities
caused by factors external to the project shall be indicated in the work activity schedule.
The schedule should include frequent milestones that can be assessed for achievement
using objective indicators to assess the scope and quality of work products completed at
those milestones. Techniques for depicting schedule relationships may include
milestone charts, activity lists, activity Gantt charts, activity networks, critical path
networks, and PERT.
See PMP from Microsoft Project for the schedule (will copy and paste once ok’d and
verified).
5.2.3 Resources allocation
This subclause of the SPMP shall provide a detailed itemization of the resources
allocated to each major work activity in the project work breakdown structure. Resources
shall include the numbers and required skill levels of personnel for each work activity.
Resource allocation may include, as appropriate, personnel by skill level and factors
such as computing resources, software tools, special testing and simulation facilities,
and administrative support. A separate line item should be provided for each type of
resource for each work activity. A summary of resource requirements for the various
work activities should be collected from the work packages of the work breakdown
structure and presented in tabular form.
See PMP from Microsoft Project for resource allocation (will copy and paste once ok’d
and verified).
Aside from personnel, there are no further resources that must be acquired to implement
this project.
5.2.4 Budget allocation
This subclause of the SPMP shall provide a detailed breakdown of necessary resource
budgets for each of the major work activities in the work breakdown structure. The
activity budget shall include the estimated cost for activity personnel and may include, as
appropriate, costs for factors such as travel, meetings, computing resources, software
tools, special testing and simulation facilities, and administrative support. A separate line
item shall be provided for each type of resource in each activity budget. The work activity
budget may be developed using a spreadsheet and presented in tabular form.
There are no further resources that need be acquired to implement this project.
Furthermore, there are no other costs for any other factors.
5.3 Control plan
5.3.1 Requirements control plan
This subclause of the SPMP shall specify the control mechanisms for measuring,
reporting, and controlling changes to the product requirements. This subclause shall also
specify the mechanisms to be used in assessing the impact of requirements changes on
product scope and quality, and the impacts of requirements changes on project
schedule, budget, resources, and risk factors. Configuration management mechanisms
shall include change control procedures and a change control board. Techniques that
may be used for requirements control include traceability, prototyping and modeling,
impact analysis, and reviews.
(Rough draft – feel free to change it. I’m not sure if we should write all these plans as if
this document was created at the beginning of the project or with what we have done up to
this point and plan to do next)
The first set of detailed requirements were triaged in must do, optional or neither of the
above categories. The must do requirements were implemented within the first iteration.
Most of the optional requirements will be distributed for implementation in future iterations.
Since new requirements and/or enhancements are being identified during the testing
phase, they will be prioritized for implementation.
Requirements gathering is collected and documented in Microsoft Word and then posted
on the project Wiki for record keeping and collaboration.
5.3.2 Schedule control plan
This subclause of the SPMP shall specify the control mechanisms to be used to
measure the progress of work completed at the major and minor project milestones, to
compare actual progress to planned progress, and to implement corrective action when
actual progress does not conform to planned progress. The schedule control plan shall
specify the methods and tools that will be used to measure and control schedule
progress. Achievement of schedule milestones should be assessed using objective
criteria to measure the scope and quality of work products completed at each milestone.
Microsoft Project will provide a comprehensive assessment for our records indicating
project completion times.
5.3.3 Budget control plan
This subclause of the SPMP shall specify the control mechanisms to be used to
measure the cost of work completed, compare planned cost to budgeted cost, and
implement corrective action when actual cost does not conform to budgeted cost. The
budget control plan shall specify the intervals at which cost reporting will be done and
the methods and tools that will be used to manage the budget. The budget plan should
include frequent milestones that can be assessed for achievement using objective
indicators to assess the scope and quality of work products completed at those
milestones. A mechanism such as earned value tracking should be used to report the
budget and schedule plan, schedule progress, and the cost of work completed.
Because no additional cost or resource items are being implemented, a budget control
plan has not been implemented.
5.3.4 Quality control plan
This subclause of the SPMP shall specify the mechanisms to be used to measure and
control the quality of the work processes and the resulting work products. Quality control
mechanisms may include quality assurance of work processes, verification and
validation, joint reviews, audits, and process assessment
The QA process will occur more frequently in the later stages of the project as it nears
completion. (Ahmed, maybe a little elaboration for what you plan to do?)
5.3.5 Reporting plan
This subclause of the SPMP shall specify the reporting mechanisms, report formats, and
information flows to be used in communicating the status of requirements, schedule,
budget, quality, and other desired or required status metrics within the project and to
entities external to the project. The methods, tools, and techniques of communication
shall be specified in this subclause. The frequency and detail of communications related
to project measurement and control shall be consistent with the project scope, criticality,
risk, and visibility.
Wikispaces.com
The team is using wikispaces.com (http://cs633group6.wikispaces.com/). This site provides us with the
ability to create a project wiki that also functions as a general information repository. In addition to
that, it is being used for other purposes (described below), which consolidates the project artifacts and
team communication in one space.







The wiki is easy to set up and team members can be added fairly easily
The creation of pages in the wiki is easy
Each page in the wiki can have separate discussions that can be threaded based on topics
Issues, questions and comments are reported in the form of discussion threads in one page,
acting like a defect repository
Integration of widgets on every page has enabled the inclusion of Google Calendar on one page
to track all team meetings
Files can be uploaded and members can see all uploaded files in the same wiki
All changes to the wiki can be quickly tracked in one page (Recent Changes) helping the team
members get a quick update about the project.
The main motivation to use wikispaces.com for our team was to minimize the number of tools each
person must check in order to get the latest overall picture of where the project stands at any given
time. Taking the example of Intel1, we wanted to use as small of a set of tools as possible to be able to
quickly gather the latest updates to the project and proactively discuss the progress on the project.
Skype
Initially we considered FreeConference.com but decided against it as we could leave messages in the
Skype chat window that can be seen by anyone in the group once they log in. In addition we can share
files while in the call.
Microsoft SharedView
Initially we wanted to use Skype as the all-encompassing tool for our team conference calls. In the first
team meeting we discovered that Skype charges fees for sharing screens with multiple users. The length
of this project did not justify that cost, so we reverted to Microsoft SharedView which has been used by
all team members and is free of charge.

The first item addressed as a team at our first meeting was how often we were going to meet in
real time to discuss the assignments. We agreed that the team was going to meet at least twice
a week, via web-conferencing, on Tuesdays and Sundays at 9pm ET. The Tuesday meeting is
dedicated to discussing the assignment for that week, and the Sunday meeting is dedicated to
integrating what the team has worked on to be submitted to the facilitator the following day.
Any other meeting required in between is scheduled as needed.
Having this regular rhythm of interaction has helped us to synchronize and coordinate the
project and responsibilities1.

During the Tuesday meeting, we also set up a deadline to present drafts on what the team is
working on to be posted on our wikispace so everyone can review and comment as needed. It
depends on the amount of work to be completed, but until now we have agreed to post drafts
on Thursday night so that we have Friday and Saturday to review, add suggestions and
comments to each other’s work, and then edits are made before our second meeting on
Sunday.
Having these deliverables for everyone’s review, either if they are complete or incomplete, has
helped us to make sure we are all in the same page and discover problems before is too late and
avoid rework1.

We have attempted to standardize our communication protocols. The wikispace has been our
common repository where we store all documents created for the assignments with their
respective version, the minutes for our weekly meetings, the progress of the application we are
working on, and the calendar with the meetings scheduled. Any comments related to these
items are made in the discussion section within the site and Vista email is only being used for
light discussion (i.e. the assignment has been submitted to the facilitator). Otherwise, the team
is notified via wikispaces (for example, an item, discussion, or change has been posted to the
wikispace).
Using the wikispace for comments on the work being done has helped to reduce email overload
and information can be retrieved by any team member as needed2.

The team has done something similar to the “White/Yellow Pages” described in chapter 82. We
have exchanged contact information, our availability in case we need to meet as group outside
the meetings scheduled, and our work experience.

Because we haven’t had a chance to meet face to face and can’t have on-site meetings, we
mainly rely in IM (Skype) for our regular meetings and to socialize any other time the team
happens to be connected during the week. These interactions have helped us to get to know
each other better and achieve higher levels of trust2.
5.3.6 Metrics collection plan
This subclause of the SPMP shall specify the methods, tools, and techniques to be used
in collecting and retaining project metrics. The metrics collection plan shall specify the
metrics to be collected, the frequency of collection, and the methods to be used in
validating, analyzing, and reporting the metrics.
No metrics collection plan is in place. Due to a truncated timetable and the small scope
of the project, this is not a necessary addition.
5.4 Risk management plan
This subclause of the SPMP shall specify the risk management plan for identifying,
analyzing, and prioritizing project risk factors. This subclause shall also describe the
procedures for contingency planning, and the methods to be used in tracking the various
risk factors, evaluating changes in the levels of risk factors, and the responses to those
changes. The risk management plan shall also specify plans for assessing initial risk
factors and the ongoing identification, assessment, and mitigation of risk factors
throughout the life cycle of the project. This plan should describe risk management work
activities, procedures and schedules for performing those activities, documentation and
reporting requirements, organizations and personnel responsible for performing specific
activities, and procedures for communicating risks and risk status among the various
acquirer, supplier, and subcontractor organizations. Risk factors that should be
considered include risks in the acquirer-supplier relationship, contractual risks,
technological risks, risks caused by the size and complexity of the product, risks in the
development and target environments, risks in personnel acquisition, skill levels and
retention, risks to schedule and budget, and risks in achieving acquirer acceptance of
the product.
The project does not inherently have a great amount of risk except in the programming
phase itself. Given this singular risk, implementing a risk management plan is illogical.
5.5 Closeout plan
This subclause of the SPMP shall contain the plans necessary to ensure orderly
closeout of the software project. Items in the closeout plan should include a staff
reassignment plan, a plan for archiving project materials, a plan for postmortem
debriefings of project personnel, and preparation of a final report to include lessons
learned and analysis of project objectives achieved.
Due to the projects nature and scope, a formal closeout plan has not been implemented.
However, it is anticipated that formal questions will be posed to illustrate that various
goals have been met and learning has occurred.