Sample Project 1
Overview
The city is looking to update an aging IT and hosting infrastructure to modernize and
support rich applications into the future, and reduce costs of maintenance of obsolete and
aging infrastructure.
The purpose of this document is to provide an overview of our process to achieve the IT
upgrade and to outline an overview of the application migration process, including some
details about deliverables and resources needed.
Infrastructure Upgrade
Architecture
The new architecture is compared to the existing architecture as show in Table 1. “Overview
of Technology Stack Upgrades”.
We have chosen in this case to retain a strong UNIX-based approach, but now we rely on
open-source alternatives with the choice of the operating environment CentOS. CentOS is a
binary mirror of Red Hat Enterprise Linux, so if a commercial alternative is desired, Red Hat
can easily be substituted. The costs of using CentOS will be lower, but not considerably
lower considering the need for a third-party support plan if the open-source alternative is
employed.
Apache is recommended for the web server and app server because of its ubiquitous nature
and the abundance of best-of-breed add-ons and open-source projects that abound for this
platform. For the next decade or more, Apache will remain the dominant platform for
Enterprise development.
Existing
Updated
OS
Solaris
CentOS
Web Server
Sun iPlanet
Apache
App Server
Oracle
Tomcat
Runtime
Java 1.4
Java EE
Database
Oracle
MySQL
Table 1. Overview Technology Stack Upgrades
A Microsoft platform was thrown-out early in the decision process because it is felt that
although Microsoft provides a rich enterprise development and hosting infrastructure, we
feel it would be more suited to C# application environment. Since we are already invested
heavily in Java, we choose not to migrate the apps from Java to C#.
The mode to Java EE from is an obvious one. The Java EE architecture is fully compatible
with the existing application environment, and the Java EE development environment is
proven robust and scalable.
Figure 1: Proposed Infrastructure Overview
Figure 1: Proposed Infrastructure Overview
Internet
Routing
Caching DNS
Zone A
Internet
Load Balance Tier
Zone B
Web Instance
Tier
Multiple Availability Zones
Eliminate Dependencies
and make it possible to
schedule downtime on a Zone
without impacting uptime
Internal Utility
Network
Internal Load
Balancing
App Server
Tier
Cache Servers
MySQL Proxy
Master
Slave
Slave
Slave
Database Tier
For the database, we chose MySQL for its enterprise capabilities and for its best of breed
scalability. With MySQL running in the appropriate configuration, we can achieve much
higher scalability that the specification requested.
Load Balancer: For the load balancing, HAProxy http and tcp load balancer can be used as a
highly available, scalable software solution.
“HAProxy is a free, very fast and reliable solution offering high availability, load balancing,
and proxying for TCP and HTTP-based applications. It is particularly suited for web sites
crawling under very high loads while needing persistence or Layer7 processing.
Supporting tens of thousands of connections is clearly realistic with today’s hardware. Its
mode of operation makes its integration into existing architectures very easy and riskless,
while still offering the possibility not to expose fragile web servers to the Net”
Hardware
Hardware will be based on commodity servers to achieve the best performance at low cost
point. We will not propose to purchase “premium” supported hardware from the top
enterprise vendors. Instead, we will focus on building a local “cloud” based infrastructure
on common, low cost hardware that can be easily replaced or substituted.
Apache Hadoop: The use of the Hadoop framework and HDFS (Hadoop distributed file
system) will be an important consideration here. Because we are suggesting the use of
commodity hardware, we will abstract the hardware layer from the OS by using Hadoop
framework to provide a fault-tolerant distributed file system that can be deployed on the
lower cost hardware. Throughput access for application data shall be exceeded for large
datasets.
A sample server configuration:




Dual or Quad Xeon processors (6-8 cores)
128GB ECC RAM
Local SSD Storage
Connection to network and storage SAN by iSCSI and Fiber Channel Technology
Application Migration Process
Overview
The core IT applications that have been identified must be migrated to a new infrastructure
to alleviate the high costs of supporting older and obsolete systems and apps. The older
apps have lost flexibility and there are significant support challenges for the organization
trying to maintain platforms that are on the verge of sun setting for their support lifetimes.
The migration will reduce costs and result in significant cost savings for the next decade or
more.
The business critical apps are to be migrate and re-hosted. Working together with the client,
we will be able to achieve the application migration according to the general project
methodology presented below. We possess the skills and know-how to achieve the
application migration and re-hosting on a time and cost effective basis.
Assessment
The type of migration is essential to understanding the cost and complexity of the new
application environment. Options include:





Operating Systems migration
Language migration
Code migration
Process migration
User operability and UI migration
In our case, we are obviating the need for OS migration and possible code migration.
Strategies for migration include:

Comprehensive Migration: In this strategy, the cost is high, but it is desirable to
implement this strategy because it often results in the most satisfactory long term
prognosis for the future of the application since the code is fully analyzed and the
systems are migrated at the code level.

Partial Migration: A more cautious approach involves iterations of migrations.
Sample cases included migrating database only, then proceeding to library
migration and finally to user interface or client app migration as a last stage. The
overall cost can be lower, but user satisfaction and long-term support options may
be more limited with this approach.
Having selected to move forward with a new infrastructure, application migration is a
necessity. The process of application migration can be long and costly, but is mitigated in
this case because both platforms are based on Java which is a language that is highly
platform and hardware independent. The selection of the new Java-based infrastructure is
heavily weighted to this concern, and the cost savings realized by this decision.
The assessment phase of application migration is a key component to increase efficiency
and reduce cost of the overall change to a new platform. Failure to perform a sufficient
assessment could impact the overall costs and timeline of the projects. It is extremely
important for vendor and customer to work closely at this stage, with on-site vendor teams
taking a leadership role in the assessment process.
How to determine the feasibility of the current applications? There are a number of decision
points that must be made and taken into consideration. Among them are:






Overall goals of the project
Project outlook for the future
Application business value
Requested enhancement and application roadmap
Changes to business needs
Requirements for scalability






Requirements for heavier multimedia loads
Development environment constraints
Constraints of in-house development and support skills
IT infrastructure constraints
Application complexity
Quality assurance
City responsibility during this phase would be to provide subject matter experts to
qualitatively and quantitatively assist in the determination of these decision points for each
of the apps to be migrated.
The following questions must be answered during the assessment phase for each
application:
What is the application functionality?
Are there off-the-shelf or third party applications that are superior to the existing app?
What are the transmission protocols used by the app?
What is the nature of the data transmitted?
What are the application inputs and outputs?
What are the application interfaces?
What are the application external dependencies?
What are the legacy file formats that the application deals with? How are they handled?
If the application was removed from production, how would that impact the
organization?
What is the total cost of ownership of the application?
Code quality is the next step in assessment. In this stage source code is analyzed for each
application, giving the code team a look at the quality and quantity of code, and how it is
structured and organize. At this stage, code may enter a source code repository if it is not
already in place. A common open-source and extremely popular source repository is SVN.
Metrics for this stage include code complexity and development environment efficiency to
help the team understand the costs and effort associated with the migration effort.
Application size, dependencies and overall stability are also factors.
Some questions may arise during this stage.
How many lines of code? What is the application size?
What is the structure of the code libraries and modules?
What are the data sources?
What user controls and forms are active?
What are the application’s functions, what features are supported?
What features are not supported?
What roadblocks are present to preclude automatic migration?
What external dependencies such as third party or licensed tools or components are
present, and what external mappings are present?
Is the application stable or is it in the process of enhancement?
Finally, the development team skills are assessed to match the requirements above. Also the
development environment is analyzed to ensure it is up-to-date and able to handle the new
applications once they are migrated and re-hosted. This may be a non-trivial expense
considering the costs of development tools, seats and licensing.
The development team must be intimately familiar with the applications in order to make
the project a success. Anything short of expert level knowledge could increase the risks
associated with a successful outcome. At this stage the City’s cooprate is essential in
understanding the applications from the development perspective, and transferring that
knowledge via comprehensive documentation is essential.
Pre-Migration Preparation
Upon completion of the assessment phase, the application migration team moves to the premigration preparation phase. The core function of this phase is to rebuild the application in
the new environment and run test cases to determine the failure points and to prepare the
source code for the migration step.
Key stages and risks for this phase are:
Subject matter experts provided by the City and vendor are needed to provide accurate
understanding of the migration results
All application resources, documentation and source code are fully cataloged and
accounted for
What are the data sources?
What user controls and forms are active?
What are the application’s functions, what features are supported?
What features are not supported?
What roadblocks are present to preclude automatic migration?
What external dependencies such as third party or licensed tools or components are
present, and what external mappings are present?
Is the application stable or is it in the process of enhancement?
Migration
The migration tool or automated migration process is employed in this step to perform the
majority of application migrations. The advantages of the migration tool at this stage is to
make the migration team more efficient. Spending the time up-front to develop the tools
will allow the migration team developers at this stage to focus on edge cases, and be
generally more efficient than if they had to write code for each individual application
migration process.
The migration tool achieves the following advantages:





Identify code issues that affect porting to the new build and production
environment.
Automate very complex processes that are repetitive and error-prone (replacement
of libraries or functions, etc.)
Remove or prune obsolete code.
Shorten the migration timeframe by eliminating the manual process of writing
common code.
Analyze common code and integration points to achieve higher optimization to the
new environment.
Report that are generated by the migration tool are analyzed by the migration team and
action is taken depending on the results of the report. In cases where an application cannot
be migrated automatically, that application moves to the next step “Application Changes”.
Deliverables for this phase:


Auto migration report.
Project plan for application changes.
Application Changes
For those apps that are not easily migrated using an automated approach, these specific
apps must be identified and manual intervention may be required. In this case, extensive
application rewriting may be required.
In many cases, a developer or developer team is required to write new code to satisfy the
application and end-user requirements.
The goal if this phase is the make sure the migrated apps for the new platform meet or
exceed the performance and functionality of the original applications.
Deliverables for this phase:


New code for manually migrated apps.
New code documentation.
Testing
Rigorous and comprehensive testing on each application is performed in this step. The same
test cases used in validating source code in earlier stages is employed here. The following
types of testing can performed at this stage:




Functional Testing: Using automated test scripts, all application functionality is
tested for all use cases.
Stress Testing: Testing is conducted to simulate the user loads in the production
environment. The apps must perform to minimum benchmarks to be considered
successfully migrated. There must be a margin of error and allowance for scaling to
higher loads to allow for future growth.
Load and Volume Testing: The effects of various loads on the system must be
simulated so the applications can perform during very high and intensive periods.
Fine tuning of the apps and infrastructure may need to occur during every phase of
testing in order to ensure the apps achieve the desired performance objectives.
Following successful testing and optimization, the app is released to the production
environment.
Deliverables for this phase.


Test Plan
Test Plan Results
Post-Migration Support
After the migration process is completed, it may be necessary to fix issues with end-user
and business logic, requiring a technical team including developers and system support
technicians to identify and intervene and implement fixes in a timely manner.
This fine-tuning is considered a normal part of post-migration support. In addition to bug
fix the team may identify system and application optimizations or enhancements to the
application configuration and other fine-tuning. It is very important to be thorough in this
last stage of application migration. The entire success of the project depends on competent
and reliable support teams to carry the vision of the project to a successful completion.
Migration team members with experience in the end-to-end process will be vital to leverage
during the support stage since they acquired valuable know-how during the migration
phases and phases leading up to the migration.
Deliverables for this phase.



Support documentation
Knowledgebase
Support project plan with timeline
Migration Team and Resources
We can estimate a team at this stage to incorporate the following resources:
One (1) Full-time Project Manager
One (1) Application Architect
One (1) Full-time Tech Lead
One (1) Full-time build engineer
Three (2) Full-time Senior Java Developers
Three (2-4) Full-Time Junior or mid-level Java Developers
Three (3) Part-time Quality Assurance testers
One (1) Tech writer
Summary
In this project proposal, we have outlined the overall project plan and methodology for
updating the City’s IT hosting infrastructure and migrating the core applications to the new
platform. Upon proceeding to the next stages, we would further detail the project plan, add
more detailed resource utilization and timeframes, and refine the schedule to provide a rich
and detailed project plan to bring this methodology to fruition.
By writing a comprehensive application migration plan, we avoid the costs associated with
proactive resolution of application issues. Updating existing applications lowers cost,
extends life and drive changes to meet business success in a fast paced IT environment for
the existing environment and into the future.
Sample Project 2
Problem Statement and Project Objectives
Agency A desires to replace its existing legacy Agency Information System with a unified,
robust and enhanced Enterprise Information System catering to the Agency staff, building
industry and public needs. At present, Agency A primarily uses paper based and manual
processes and the Agency Information System is based on antiquated software tools and
data files. This infrastructure is slow and requires skills that are either no longer available
or very rate to find and very expensive to maintain. The current processes are not
documented extensively and are not standardized. There’s a need for overhauling the
permit processing and an automated permit management system can impact the Agency A’s
working considerably.
Current Environment and Systems
Agency A provides services to building industry, contractors, general public and other city
agencies. The main services provided include
123456789-
Licensing
Application Processing and Reviews
Professional Certifications and Audits
Inspections
Enforcement
Materials, Equipment & Device Certification
Maintenance Permits
Periodic Inspection Reports & Periodic Testing
Administrative Functions
The current system mostly consist of manual processes and paper forms evolved over time
based on need & utility. The main information system in use consist of ADABAS file based
database and NATURAL language code logic. There are some ancillary systems consisting of
Excel, DB2, Access & Oracle based tools/modules. Agency A requires to interface with the
following external entities




City Planning Geosupport
DOF Property
FDNY Inspections
Others
Summary
The proposed solution shall provide a centralized online access to re-engineered e-forms
and e-filing workflows as well as automated business workflows from end-to-end
processes. The legacy paper-based records shall also be converted to electronic documents,
processed and tagged under the appropriate records/cases/proceedings accordingly. The
online system shall provide role based activity driven user interfaces customized to each
user/role type and their business needs. The system shall be deployed in a modular
approach in iterations. In this way the business continuity can be ensured and the
organizational transition from legacy system to new enterprise information system can be
kept manageable and focused.
Proposed Technical Solution
The proposed solution consists of the following modules that would interact with each
other as and where needed.
1. ECM module: consisting of legacy documents repository and content management
system for all content and re-engineered / hosted forms & e-filling. Streamlining of
the forms & application processing shall be implemented wherever possible
2. Workflow module: automation of all (in-scope) the business processes, forms
submissions, licensing, application processing, reviews, approvals, permits,
inspections, certifications, audits, etc. that currently exist as NATURAL routines or
manual processes or combination of both. This module shall replace the current
paper-based forms any legacy system forms / processing with online web-based
forms, manual and legacy NATURAL based business processes re-engineered,
automated and integrated with ECM system to progress each business process
3.
4.
5.
6.
7.
following the current steps. Furthermore, quality control measures would be builtin to the automated business processes to enhance quality and overall management
& administrative control.
Database module: Relational database providing all the data needs for ECM &
Workflow modules. The data model shall be re-engineered based on current/legacy
ADABAS files as well as current & future needs of the entire system.
BI & Reporting module: providing various reporting and BI information.
GIS overlay module: integrating with the ECM, Workflow and Reporting & BI
modules to provide geographical mapping and spatial relevance to the information
(where applicable & available)
Mobile interface overlay: providing integration with handheld devices for
interfaces/functionality that is needed out in the field (inspections and other
business processes).
Web Service interfaces: providing interchange of information between Agency A’s
ECM/information system and any partner systems to exchange information/data
with.
ECM solution(s) recommendations
Based on the technical and business requirement our recommended solution is based on
SharePoint 2013 document management, workflows and Business Intelligence services.
SharePoint 2013 provides comprehensive functionality for Enterprise Content
Management, Document Management and Business Workflow Automation right out of the
box. It has built-in integration with Microsoft Business Intelligence services to provide
highly advanced reporting and dashboards.
SharePoint 2013 provides unified framework for










ECM
GIS system interfacing
Workflow automation
Approval processes
BI and Reporting
Mobile devices interface
Active Directory integration
MS SQL server native backend DB, choice to use Oracle?
Scalability & load distribution
Multi-lingual content support
Compared to open-source ECM systems MS SharePoint is well documented, with an
abundant poll of development resources and backed up with technical support. It is very
flexible for out-of-box customizations as well as custom developed code. It is naturally
integrated with MS Office, Exchange, and Windows Server Family/Active Directory. It
has built-in support for reporting & BI.
Integration with GIS & external systems
Proposed Enterprise Information System shall incorporate SharePoint 2013’s built-in GIS
capabilities to integrate buildings related information, permits, complaints, inspections,
applications & approvals etc. with spatial data to provide geographical representation.
Implementation Strategy
Business Process Re-engineering Approach
As we shall be working with a live system having many moving parts, we shall follow the
NYC Project Hybrid approach to migrate the business processes off the legacy system onto
the new solution platform. The initial phase of analysis will concentrate on investigating
sub-system boundaries and interactions to determine what sections can be isolated to what
degree for switch-over and what kind of temporary interconnectivity would be needed
between new solution platform and legacy system during transitions providing zero-tominimum down time for business process continuity. As the individual sections are being
switched-over, there shall be a need to develop logic to connect the new solution and legacy
system. Depending on the nature of the sections/modules involved, this can be backend
data synchronization or information interchange automation or any such approach. The
specifics of this shall prevail during the analysis and design phases.
Analysis and Design
Initial Investigation
This phase shall identify the current system functionality on a high level and determine
breakdown of iterations for migration/re-engineering and rollout of new solution.
Framework Design
Framework design process shall begin with an initial comprehensive framework &
architecture for the entire solution on a high-level. Then followed by elaboration with each
iteration for in-scope functionality.
Business Analysis
Business Analysis phase shall be an iterative process that shall take a deep dive into each
iteration’s scope of business processes, document the processes, forms, backend
functionality and connectivity with the rest of the system.
System Design
System Design will also follow the iterative approach limiting the scope to the
functionality/processes selected for the iteration and aligned with the high-level system
design for entire solution. The system design phase shall address the design of automated
business processes, re-engineered & new backend processes, forms in the scope of current
iteration and inter-connectivity with the legacy system.
Database Design
Database design shall follow an initial comprehensive database design followed by iterative
design additions related to the processes and forms in scope of current iteration.
Data and Document Conversion Strategy
As part of the proposed solution all the legacy data would be re-organized and ported into
the new database. All the paper documents shall be scanned and indexed/tagged and
related case/processing history from the legacy system will be migrated to the new ECM
along with the scanned versions of the paper forms, proceedings, licenses etc. These
activates shall be carried out in parallel with the Enterprise Information System
development & rollout.
Data Migration Approach
Existing ADABAS data files shall be analyzed to identify entities and tables needed to port
the legacy data into new robust database model. There might be requirement to normalize
the entities & tables/files in ADABAS. The legacy data in the data files would be processed
for data cleansing and removing duplicates (if any exist) before it is re-organized/converted
and loaded into the new database
Document Capture and Load Approach
Existing / historic documents would be analyzed to determine and define metadata needed
to index/tag the documents appropriately to link with the records and proper
organization/retrieval in ECM. Document Scan/Processing Automation process shall be
defined according to the amount of documents and scope of each iteration. All the in-scope
documents shall be scanned, indexed/tagged and stored into the ECM, filed appropriately
with the relevant records.
It is anticipated that the amount of documents/paper based forms to be converted/scanned
can be extremely large and would require redundant manpower to scan and process all the
documents in reasonable time. Document processing training plan and training material
shall be developed so new resources can be on-boarded in a very short time and the pace of
document conversion process can be maintained.
Testing strategy
EWS follows the multiple-cycles based testing approach. For each iteration, the scope of
testing shall be defined along with the deliverable definition. At the minimum each testing
phase shall contain 2 test cycles. The first cycle may include multiple point releases as any
detected bugs/issues are worked on and fixes are provided to QA for retesting. As all the
identified/in-scope issues are fixed, the second cycle of testing shall start and verify the
complete functionality of the deliverable of the iteration.
Document Test
Scripts / Procedure
Steps
Determine Test
Bed Requirements
Release available
for Testing
Test
Test Cycle
Cycle
Bug
Bug Fixing
Fixing
Prepare Test Bed
Review & Priorities
Issues
Reset Test Data
Assign Issues
Test Scrips
Execute Test
Scripts / Procedure
Steps
JIRA
Bug Reports
Verify Issue
Yes
Actual Result
Match
Expected Result
Reproducible
Functionality
Accepted
No
Determine Severity
and Nature of
defect/issue
Yes
Fix
Training Approach
The new Enterprise Information System shall have a number of user roles and user groups
defining the functionality of each business role, the way each user shall access and utilize
the system would also be different for each user. Each user group shall require training
customized for their job/role. The determination of training objectives & user groups shall
be part of the initial analysis and revisited in each iteration. Depending on which
modules/functionality is being rolled out, the training needs and groups shall be
determined and appropriate training materials shall be developed. Trainings shall be
scheduled such that the staff’s regular daily activities are least disrupted and they can be
trained to the new system/functionality and how they are to process their usual daily tasks
during the Business continuity phases and after the complete deployment of the entire
Enterprise Information System. Selection of training tools and methodologies shall be
determined based on each training objectives, scope and audience. The training tools may
consist of group sessions, presentations, on-line training material, workshops,
walkthroughs or any combination of these tools. After each training there shall be an
evaluation of the trained staff to ensure that the training objectives have been met and the
trained staff is ready to use the new functionality/system.
Various tools and templates will be utilized to manage the training process. Some of the
sample templates are provided below.
1
Document Scanning, Tagging
and archiving process
2
Working with legacy documents,
forms, cases in new on-line
system
3
Online workflows walkthrough
Managers
Office Staff
Public facing
Staff
Administrators
Total
IT Help Desk
Staff
Training Goals
Clerical Staff
Sample Objectives & Users Matrix
4
5
6
Sample Training Evaluation
Training Goals
User Group
Total
1
Document Scanning, Tagging
and archiving process
2
Working with legacy
documents, forms, cases in
new on-line system
3
Online workflows
walkthrough
4
5
6
Trained
Competency*
Adequate
Average
Inadequate
Verification of current and historical data repository
Due to the nature of this conversion/migration project that involves concurrent technology
upgrade and data migration, it is essential that the migrated data is verified against the
historic records. This activity shall be included as a phase in project to review and verify the
imported data and records with the Agency A staff. Both active and archived records/data
shall be reviewed to
Continual collection of new data on the old manual system
As this solution shall be rolled out in iterations and different modules/functionality maybe
rolled out in such way that some part of the business process needs to be conducted in new
environment while other steps are still in the legacy information system. To provide
rollback capabilities for each such module deployment, the in-scope process and relevant
data shall be backed up to the legacy system using custom code development to integrate
with data management routines in the legacy system. When a business process step is
moved to new system, the data being stored through that step shall also be stored in to
legacy system such that the legacy system will always be current and reflecting all the new
interactions taking place. It is possible that the new solution may contain more data fields
compared to legacy system so only the data fields that already exist in the legacy system
shall be reflected back and no change in data model of legacy system shall be made to
maintain its integrity. By following this approach, the legacy system can be reverted back to
if the newly deployed module faces any issues or users need more training on the new
system or any such scenarios.
Business continuity / DR process
Along with following DoITT guidelines for DR and business continuity processes, EWS shall
ensure that a robust and comprehensive disaster recovery process is in place for the entire
solution. This would include the following;



Periodic backups of entire system, database and content libraries
Monthly & Weekly incremental backups of database and content libraries
Daily incremental backups of database and content libraries
The backups shall be maintains both on premise and off-site to provide coverage for loss of
data/code as well as loss of primary location.
Considering the amount of transactions and volume of data/content to be processed by the
system on a daily bases, the solution shall have built-in redundancy on server level. Multiple
physical servers shall be configured as failover database server, ECM/content server and
web server.
Assumption & Questions
Assumptions





All forms and templates shall be provided for analysis
Requirements & scope of the interface with other NYC departments is well
documented
The relevant staff of Agency A shall be available for analysis meetings and business
domain understanding.
All the physical documents are appropriately and adequately indexed
The business processes are common and unique across the organization
Questions








What is a high level estimate of applications, permits & inspections processed per
month?
Is there a predictable stretch of time when the frequency of regular business is at
the lowest?
Can it be estimated how many physical pages are accumulated as historic
documents?
Total how many system users currently exist and how many are anticipated for the
new automated workflow based system (Agency A employees)?
Would anyone outside the Agency A require some kind of user access, for example
staff of NYC or other Agencies under NYC?
What are the primary needs for Business Intelligence?
Does DoITT already has an existing SharePoint environment? If so, what version and
configuration?
Is there an expected time for completion for the new solution?
Effort Breakdown
The deliverables and their relative %age to the complete solution is as follows;
Deliverable
Relative %age to Entire
Solution
ECM Module
20%
Workflow Module
30%
Database Module
20%
BI & Reporting Module
10%
GIS Overlay Module
5%
Mobile Interface Overlay
10%
Web Services Interface
5%
For each deliverable/iteration the effort distribution over different phases is given below.
Note that the given ratios are a high level distribution and for each deliverable/module that
can be a little different.
Phase
Relative %age to entire
Iteration / Deliverable
Planning Phase
7.5%
Analysis Phase
10%
Design Phase
15%
Build Phase
45%
Test Phase
15%
Deploy Phase
7.5%
Roles & Responsibilities
The following resources shall be deployed on the project
PM – Overall manager and coordinator of all project activities
SharePoint Solution Architect – responsible for design and architecture of solution
Tech Lead(s) – responsible for development team(s) working on deliverables
Developers – development resources responsible for working on build tasks
QA Lead(s) – responsible for QA/testers team(s)
Testers – QA resources responsible for testing application
Database Designer – responsible for database customization and design
SharePoint System & Deployment Engineer – responsible for SharePoint configurations,
solution management and deployments.
UI Designer(s): responsible for developing user interfaces and frontend of the solution
Project Management & Risk Strategy
Risk Management Process
Risk
Management
Start
Risks
Identify Risks
Develop
mitigation
strategies and
contingecy
plans
Report Impact of
Risk Occuring
Monitor Risks
Risk
Occurs
Report Risks
Execute Contingency
Plan /
Re-plan Project
Risk
Management
End
Risk Ranking
Frequency
Description
Weight
Frequent
may occur regularly
3
Occasional
may occur but not too often
2
Rare
may only occur once or twice
1
Probability
Description
Weight
Probable
likely to occur
3
Possible
equal chances of occurrence and otherwise
2
Remote
highly unlikely to occur
1
Severity
Description
Weight
Show stopper
Will halt the project, progress cannot be made before
the problem is resolved
4
Critical
Will cause halt to some vital module of the project, but
not completely stop the whole project
3
High
Will cause serious delays in project OR extra expense
2
Low
Low impact, may not pose any critical threat, but may
hinder the optimum progress
1
Risk Impact
=
( Frequency ) X ( Probability ) X ( Severity )
Sample Risk Register
ID
1
Risk
Resource availability on required dates
Owner
Frequency
Probability
Severity
Mitigation Plan
Contingency
Trigger
Contingency Plan