4. Business Case
Introduction
SHAMIANA – The Short Film Club is a part of „Two Plus Productions‟ has been in the forefront in
the business of short film exhibition and distribution for the last nine years and is now actively producing
short films. SHAMIANA is a very unique initiative that has gathered a huge following for itself in a short
span. With over 3 million people (and growing) across various countries following the club, it‟s soon
becoming into a cult. They are into business of screening some of the best award-winning short films ever
produced including Oscar winners, National Award winners, Golden Globe winners, Cannes winners,
Berlinale winners, etc. They have showcased approximately 1000 films in the last 3 years.
SHAMIANA is on its way to becoming the biggest brand in the alternative space of short films and
with the way the film club has taken off in the last ONE YEAR (reaching out to over 3 million across the
country). SHAMIANA has already attracted some powerful associations like, MICROMAX MOBILES,
ZYDUS WELLNESS, CLEARTRIP.COM, and other tie-ups across the country including Times Card,
Radio Mirchi, etc.
Business Objective
SHAMIANA has been growing for the last few years phenomenally. To expand its reach and imprint
its existence in the essence of customers SHAMIANA has to take leaps into the business of marketing itself
which it has not done so actively. SHAMIANA has been active on the front of marketing through its
facebook page and its own webpage.
To actively involve customers who visit its web pages SHAMIANA looks to create a few web based
gamming applications. A few though of applications were developing of a web based Dart application or in
animated movie application that would captivate the customer‟s application and also allow the spread the
knowhow of SHAMIANA to other friend and users connected to present customer on facebook.
Facebook is chose to be the base of launch of this application as its perceived to be most cheapest
and booming platform to communicate with customers from the point of view of SHAMIANA.
Current Situation and Problem/ opportunity statement
With the advent of information technology and world moving to a internet dependent
communication platform there has been many web based marketing platform that has been available in the
market today. Facebook is one of the communication platforms for marketing.
Page4
5. SHAMIANA is one of the initiatives that have a very short reach of 9 cities in the whole country.
There cities span Delhi, Bangalore, Mumbai, Ahmadabad, Pune, Baroda, Goa etc. Each of these expansion
and knowhow lets SHAMIANA to expand to a new customer base and hence to a different territory of
customers and hence allowing growth in number of customers.
SHAMIANA has found that facebook a very ardent platform of communicating and captivating the
customer‟s attention. This project if successful would provide a gamut of benefits as follows:
1. Free promotion: This application if successful would help in achieving free promotion.
2. Exponential spread of knowledge about the firm: As the application is basically targeted to be
launched on facebook as a platform, with the help of data sharing features that facebook allows it
can be easily passed on to from one friend to another and hence improve the overall knowledge
about SHAMIANA.
3. Market survey: This if successful would also help in launching different region based market
survey such that it can be expanded into different geographic location across the country.
4. Easily accessible.
5. Increase of visibility of SHAMIANA
6. Customer engagement: These applications will allow to have a direct engagement of customer.
Critical Assumption and Constraints
The proposed dart application must be a valuable asset for SHAMIANA in terms of increasing its
visibility and reach into customer base. It also needs to be able to perform customer engagement on a
positive note. It should not adversely affect the customer base in terms of depleting the existing base of its
customers. The most deathly constraint that SHAMIANA faces being only 3 years old is that of financing the
present development. The funds that has been allocated by SHAMIANA for the current development is
50,000 INR.
Analysis of Options and Recommendations
There are three options for addressing this opportunity:
1. Do nothing. SHAMIANA is doing well, and might be able to continue to operate without this
new project. The rate at which number of customers has been growing is phenomenon at the present stage.
This project is based on the fact that facebook is a vast platform of promotional activity and helps to rope in
new customers if they are made to be involved into some application. (i.e. the application on facebook are
easy ways to rope in the customer involvement)
Page5
6. 2. Purchase of external software: There are many off shelf facebook and flash application like
angry birds and lord of Ultimatum etc. that are available for free and some for a minimal cost. But
SHAMIANA‟s motto to build application is not only to get customers involved with it but to drag them into
knowing and getting involved with SHAMIANA as a whole. So these off shelf application either will not
help or will need to be highly customized to suit for the same.
3. Design and implement by Vendor: The new intranet based application could be outsourced to an
external vendor who would then code and develop the front end of the project. Hardware required for the
project would be outsourced initially to some server hosting client. In accordance to the changes in the future
scenario of success of the software these might be a server buying decision.
Based on discussions with SHAMIANA, we believe that option 3 is the best option to work on
though the costing seems to be on a bit higher end.
Preliminary project requirements
The main features of the facebook based application include the following:
1. Eye catching graphics to catch customer‟s attention immediately.
2. Allow upload of photograph or brown photo on web to serve as the basis of Dart application
developed.
3. Application needs to be easy and light to be loaded on computer with basic requirement.
4. Also needs to have records and display personalized records on global basis.
Budget estimates and financial analysis
Actual heading Cost Estimation
Cost of leasing hardware 5000-6000 INR /annum
Cost of code development 20,000-25,000 INR
Cost of front end development 25,000 INR
Maintenance cost 2000 INR/ month
The project has a potential to fetch in customer from varied background and varied taste and
preferences. Hence the amount of intangible branding that the application can develop is huge. In terms of
adding the number of customers on an average of 400/ month and if the conversion of customers on
facebook to real life is approximately 10% that gives be 40 customs/ month. i.e. approximately 500
customers per year that is a huge potential of growth. All these values are just data that are found from a
Page6
7. survey that is circulated internal in many Google and facebook group and hence the data could be higher than
denoted value.
Schedule estimates
Activity Time estimates
Requirement estimation and analysis 10 days
Estimate of Flash ware preparation 20 days +5 days
Estimate of coding and implementation 30 days + 10 days
Hard ware deal finalizing 10 days
Final testing and go live 10 days +5 days
Total 50 days + 10 days
The project on rough estimates seems to be completed in a span of two months but the client had a
requirement of completing it in a month that seems infeasible on the face.
Potential risks
There are several risks involved with this project. The foremost risk is moving of customer base
away from facebook. There could be technology advancement in the domain of internet web based
application that may make developed application obsolete and un-acceptable to the web browser. The main
business risk is investing the time and money into this project and not realizing the projected organizational
wise benefits.
Page7
8. Project Charter
Project Title:
Dart application for SHAMIANA
Start Date: Aug 15th, 2011.
Projected Finish Date:
Initial launch of this project is going to be within 2 months of start date.
Budget Information
The organization needs to allocate 50,000 INR for this project. The majority of costs for this project
will be payment to vendors developing different parts of the project. The amount mentioned above does not
include cost like server space leasing cost and also regular maintenance and update cost. An initial estimate
provides a total of 60 days of work will be needed for completion of the project.
Project Manager
Debashish Bagg and Abhinav Kamal will share this responsibility.
Project Objectives:
Develop a new facebook based / web based application that would help customers to connect to the
work done by SHAMIANA more effectively. The web application will be a basic dart on to which you can
upload specific photos or browse from friends thus playing a interactive application that involves the
customer. It also has potential of capturing the customer responses that would give ques about continuing or
scraping the present application development going further.
Approach:
1. Develop a survey to determine critical features of the web based dart that needs to be developed
and the respective application linkages that are needed.
2. Research software to provide features needed along with the hardware that would support the
same.
3. Develop a dart application soliciting a great deal of user feedback
4. Determine a way to measure the value of application and the value that is added by the
application to SHAMIANA.
Page8
9. Roles and responsibilities:
Name Role Position Contact Information
Debashish Bagg Project Manager Debashish. bagg@gmail.com
Abhinav Kamal Project Manager abhinav.kamal@gmail.com
Project Scope Statement
Project Justification
SHAMIANA, requested this project to assist the company in meeting its marketing and hence its
growth goals. The new web based application will increase visibility of the company‟s expertise to current
and potential customers though increased involvement of customer with application of SHAMIANA page. It
will also help improve visibility and customer involvement hence spreading of customer base. The budget
for the project is 50,000 INR and will be deployed to software development by the external vendor.
Estimated benefits are at least additional 500 customers each year.
Project characteristics and Requirements:
1. Photos and dart background upload: The application needs to allow uploading photos or
browsing through friend‟s photos to fix dart background.
2. User submissions: Users submissions and their scores needs to be recorded by the program and
needs to be globally available.
3. Requests for articles: The application needs to be able to post the recent happenings on the
customers page so as to attract other non customers get attached to the application and hence to
SHAMIANA as a whole.
4. The “Refer to a friend” feature must be user-friendly and capable of soliciting user to forward
the application link to his/ her friends in a proper format. This should also be able to show friend
circle wise highest to inculcate high level of involvement among people/ customers.
5. Security: The application must not breach the internal security provided by facebook. It also
needs to ensure that there is a proper security that the data in the application is not leaked unless
intended by the user itself.
6. The intranet site must be light in terms of coding and hence be available on a basic web browser
than asking for a heavier processing at the client side..
Page9
10. Project management related deliverables:
Business case, charter, scope statement, WBS, schedule, cost baseline, final project presentation,
lessons-learned report, and any other documents required to manage the project.
Project Success Criteria
Our goal is to complete this project within two months for no more than INR 50,000. The project
sponsor, SHAMIANA, has emphasized the importance of the project paying for itself within one year after
the web application is complete. To meet this marketing goal, the web application must have strong user
inputs. We must also develop a method for capturing the benefits while the web application is being
developed, tested, and after it is rolled out. If the project takes a little longer to complete or costs a little more
than planned, the firm will still view it as a success if it has a good payback and helps promote the firm‟s
image and draw the increased number of audience as its the goal of the application.
Page10
11. Financial Analysis of the Project
Following template is utilized to calculate the estimation of human resources as per function point
analysis and data generate is as below.
SUMMARY
Project Identification
Customer Name SHAMIANA
Dart application for
Project Name SHAMIANA
Project Code
Analyst Debashish Bagg
Date
Summary Estimates
Unadjusted Function Point Count 28 From FP worksheet
Processing Complexity Adjustment Factor 1.22 From PCA worksheet
Adjusted Function Point Count (AFP) 34 Calculated: (FP*PCA)
Calibration Factor (CF) 1 See note
Total Function Point Measure (TFP) 34 Calculated: (AFP*CF)
Delivery Rate (DR) in FPs/person month 1 See note
Days per person-month (DPM) 4 See note
High Level Effort Estimate (in person-days) 137 Calculated: (TFP/DR) * DPM
The above summary can be further detailed in the following tables.
INTERNAL LOGICAL FILES (ILFs)
# of # of Complexity
List of files DETs RETs Low Average High Notes and Assumptions
Data file storing scores 2 5 1 0 0 global counter
Summary 1 0 0
EXTERNAL INTERFACE FILES (EIFs)
# of # of Complexity
List of files DETs RETs Low Average High Notes and Assumptions
interface to webpage 2 1 1 0 0
help files 1 1 1 0 0
Summary 2 0 0
Page11
12. EXTERNAL INPUTS (EIs)
# of # of Complexity
List of inputs DETs FTRs Low Average High Notes and Assumptions
User name 2 1 1 0 0
User friend list 1 30 0 1 0 Tagged
Summary 1 1 0
UNADJUSTED FUNCTION POINT COUNT (FP)
Function Type Functional Complexity Count Weight Function Points (FPs) FP %
Internal Logical Files (ILFs) Low 1 7 7
Average 0 10 0
High 0 15 0 25%
External Interface Files (EIFs) Low 2 5 10
Average 0 7 0
High 0 10 0 36%
External Inputs (EIs) Low 1 3 3
Average 1 4 4
High 0 6 0 25%
External Outputs (EOs) Low 1 4 4
Average 0 5 0
High 0 7 0 14%
External Queries (EQs) Low 0 3 0
Average 0 4 0
High 0 6 0 0%
Total Unadjusted Function Point Count 28 100%
VALUE ADJUSTMENT FACTOR (VAF)
Degree
of
General Systems Characteristics Description
Influence
(0-5)
1. Data Communications 5 The application is online
2. Distributed Processing 4 It has to be distributed calculation
3. Performance 3
Heavily Used
4. Configuration 3
5. Transaction Rates 4
6. Online Data Entry 5
Design for End User
Page12
7. Efficiency 4
8. Online Update 5 update is online
13. 9. Complex Processing 4 average on processing complexity
Usable in Other has to be reusable to be moved to other
10. Applications 4 coding if needed
11. Installation Ease 3
12. Operational Ease 4
13. Multiple Sites 5 on website and facebook
14. Facilitate Change 4 needs to allow change
Total Degree of Influence (TDI)
57 Calculated (sum of the above)
Value Adjustment Factor (VAF) 1.22 Calculated ((TDI*0.01)+0.65)
WBS for dart project
1. Dart project
1.1. Design of web application Interface (MAAC)
1.1.1. Interface specification
1.1.1.1. Functional specification
1.1.1.1.1. Interface for web browser
1.1.1.1.1.1. Create mock interface for web browser
1.1.1.1.1.2. Conduct design review internal to the team
1.1.1.1.1.3. Get design reviewed by stakeholders
1.1.1.1.1.3.1. Get design reviewed by mock users
1.1.1.1.1.4. Take consensus for the design
1.1.1.1.1.5. Create a final functional specification
1.1.1.1.1.6. Obtain individual signoff
1.1.1.1.2. Interface for mobile browser (can run simultaneously with 1.1.1.1.1)
1.1.1.1.2.1. Create mock interface for web browser
1.1.1.1.2.2. Conduct design review internal to the team
1.1.1.1.2.3. Get design reviewed by stakeholders
1.1.1.1.2.3.1. Get design reviewed by mock users
1.1.1.1.2.4. Take consensus for the design
1.1.1.1.2.5. Create a final functional specification
1.1.1.1.2.6. Obtain individual signoff
1.1.1.1.2.6.1. Signoff for interface from SHAMIANA representative body and mock users
1.1.1.2. Technical specifications (TAVARI PVT. LTD)
1.1.1.2.1. Develop the technical specifications based on the previous signoff document
1.1.1.2.2. Review the technical specifications
Page13
1.1.1.2.3. Obtain signoff from respective stakeholders
1.1.1.2.3.1. Signoff of the SHAMIANA representation
14. 1.1.1.2.3.2. Signoff of mock users if required
1.1.2. SQL Database specification (TAVARI PVT. LTD)
1.1.2.1. Develop technical specifications
1.1.2.2. Review technical specifications
1.1.2.2.1. Review by the project team
1.1.2.3. Review by external expert (SHAMIANA )
1.1.2.4. Rework technical specification
1.1.2.5. Obtain team signoff
1.1.2.5.1. Obtain signoff of the project team
1.1.2.6. Obtain signoff of the external expert if he is a stakeholder (SHAMIANA )
1.1.3. Interfaces (TAVARI PVT. LTD)
1.1.3.1. Technical specifications
1.1.3.1.1. Determine data import/ export elements
1.1.3.1.2. Design Interface
1.1.3.1.3. Obtain signoff of the respective stakeholders
1.1.3.1.3.1. Obtain signoff of the project team
1.1.3.2. Obtain signoff of the external expert if he is a stakeholder (SHAMIANA )
1.1.4. Reports (TAVARI PVT. LTD)
1.1.4.1. Functional specification report
1.1.4.1.1. Collect user requirement data
1.1.4.1.1.1. Define data elements
1.1.4.1.1.1.1. Define null or initial values if any on the screen
1.1.4.1.1.1.2. Define relative values for users i.e. any history to be maintained
1.1.4.1.1.2. Define frequency of use
1.1.4.1.1.3. Define sessions
1.1.4.1.2. Design reports
1.1.4.1.2.1. Design and develop the functional specifications
1.1.4.1.2.2. Document relationship/ flow from functional specification to technical specification
1.1.4.1.2.3. Design and develop the detailed design document
1.1.4.1.2.4. Flow from detailed design specification to test plans
1.1.4.1.2.5. Design and develop the initial testing plan
1.1.4.1.2.6. Design and develop the integration testing plan
1.1.4.1.3. Deliver the acceptance testing plan
1.1.4.1.4. Review report design with project team
1.1.4.1.5. Deliver final functional specifications
Page14
1.1.4.1.5.1. Deliver the functional specifications
15. 1.1.4.1.5.2. Deliver the detailed design document
1.1.4.1.5.3. Deliver the initial testing plan
1.1.4.1.5.4. Deliver the integration testing plan
1.1.4.1.5.5. Deliver the acceptance testing plan
1.1.4.1.6. Obtain signoff of the respective stakeholders
1.1.4.1.6.1. Obtain signoff of the project team
1.1.4.2. Obtain signoff of the external expert if he is a stakeholder (SHAMIANA )
1.1.4.2.1.1.
1.2. Procurement (TAVARI PVT. LTD)
1.2.1. Planning software needs
1.2.1.1. Determine software needs
1.2.1.2. Make software selection
1.2.2. Float the design specification to respective software vendors
1.2.2.1. Float above technical specification development
1.2.3. Get quotation from software providers
1.2.4. Compare the quotations
1.2.4.1. Compare the quotation price
1.2.4.2. Compare vendor history
1.2.4.3. Compare add on features if any
1.2.4.4. Compare the comparability and customization requirement
1.2.4.5. Compare the software provided on basis of relative ease of maintenance cost
1.2.5. Take an decision of which vendor to be accepted
1.2.6. vendor visit
1.2.6.1. Discuss with the vendor to avoid any communication gap in the specification
1.2.6.2. Discuss the broad aspects of the project
1.2.6.3. Finalize the vendor contact and date of delivery.
1.2.6.4. If failed go to step 1.2.3 for next best vendor
1.2.7. Communicate to get the software on board and start with customization
1.2.7.1. Deadline communications and reporting
1.2.7.1.1. Check with the detailed design document for specification
1.2.7.1.2. Check with testing and reporting at each stage
1.2.7.2. Involve respective stakeholders in the decision process
1.2.7.3. If failed go to step 1.2.3 for next best vendor
1.3. Customization (TAVARI PVT. LTD)
1.3.1. Installation of software
1.3.1.1. Procure the soft ware
1.3.1.2. Install the software on the existing hardware
Page15
1.3.2. Initial testing and validation of the software and its features
16. 1.3.2.1. Front end testing
1.3.2.1.1. Browser front end testing
1.3.2.1.1.1. Verify design and functionality
1.3.2.1.1.2. Perform unit testing
1.3.2.1.1.3. Perform integration testing
1.3.2.1.1.4. Perform acceptance testing
1.3.2.1.1.4.1. Perform load testing (if needed)
1.3.2.1.1.4.2. Perform connectivity testing (if needed)
1.3.2.1.1.5. Obtain signoff from the testing team and end users
1.3.2.1.1.6. Note and communicate the customizations needed
1.3.2.1.1.7. Signoff test plan for vendor
1.3.2.1.2. Mobile frontend testing
1.3.2.1.2.1. Verify design and functionality
1.3.2.1.2.2. Perform unit testing
1.3.2.1.2.3. Perform integration testing
1.3.2.1.2.4. Perform acceptance testing
1.3.2.1.2.4.1. Perform load testing (if needed)
1.3.2.1.2.4.2. Perform connectivity testing (if needed)
1.3.2.1.2.5. Obtain signoff from the testing team and end users
1.3.2.1.2.6. Note and communicate the customizations needed
1.3.2.1.2.7. Signoff test plan for vendor
1.3.2.2. SQL database testing
1.3.2.2.1. Verify design/ data elements
1.3.2.2.2. Verify the relationships
1.3.2.2.3. Perform integration testing
1.3.2.2.4. Perform User acceptance testing
1.3.2.2.4.1. Acceptance testing in terms of load
1.3.2.2.4.2. Acceptance testing in terms of integrity etc
1.3.2.2.5. Obtain user signoff
1.3.2.3. Interface
1.3.2.3.1. Verify design and functionality
1.3.2.3.2. Perform Integration Testing
1.3.2.3.3. Perform User Acceptance Testing
1.3.2.3.4. Obtain signoff from the testing team and end users
1.3.2.3.5. Note and communicate the customizations needed
1.3.2.3.6. Signoff test plan for vendor
1.3.2.4. Reports
Page16
1.3.2.4.1. Verify design and functionality
17. 1.3.2.4.2. Perform Integration test
1.3.2.4.3. Perform User Acceptance Testing
1.3.2.4.4. Obtain signoff from the testing team and end users
1.3.2.4.5. Note and communicate the customizations needed
1.3.2.4.6. Signoff test plan for vendor
1.3.3. Implement the required customization
1.3.3.1. Front End
1.3.3.1.1. Mock user front end
1.3.3.1.1.1. Customize Web pages
1.3.3.1.1.2. Conduct Unit testing
1.3.3.1.1.3. Review web page design and functionality
1.3.3.1.1.4. Get final user to test
1.3.3.1.1.5. Rework if needed for the same
1.3.3.1.2. Web front end
1.3.3.1.2.1. Customize Web pages
1.3.3.1.2.2. Conduct Unit testing
1.3.3.1.2.3. Review web page design and functionality
1.3.3.1.2.4. Get final user to test
1.3.3.1.2.5. Rework if needed for the same
1.3.3.1.3. Mobile front end
1.3.3.1.3.1. Customize Web pages
1.3.3.1.3.2. Conduct Unit testing
1.3.3.1.3.3. Review web page design and functionality
1.3.3.1.3.4. Get final user to test
1.3.3.1.3.5. Rework if needed for the same
1.3.3.2. SQL Database
1.3.3.2.1. Identify the customization in relationships of the tables
1.3.3.2.2. Build the database schemas
1.3.3.2.3. Build each data element if needed
1.3.3.2.4. Build database tables
1.3.3.2.5. Review tables with project team and external expert
1.3.3.3. Interface
1.3.3.3.1. Customize interfaces where ever needed
1.3.3.3.2. Conduct unit testing of import and export functionality
1.3.3.3.3. Sign off for interface customization
1.3.3.4. Reports
1.3.3.4.1. Code custom reports
Page17
1.3.3.4.2. Test custom reports
18. 1.3.3.4.3. Review
1.3.3.4.3.1. Review the reports with required stakeholders if needed
1.3.3.4.3.2. Review the reports with project team
1.3.3.4.3.3. Rework if there are changes needed
1.3.3.4.4. Sign off custom reports development
1.3.3.5. Track customization at every stage through different reporting mechanism
1.3.4. Final testing and validation of the software and its features
1.3.4.1. Front end testing
1.3.4.1.1. Browser front end testing
1.3.4.1.1.1. Verify design and functionality
1.3.4.1.1.2. Perform unit testing
1.3.4.1.1.3. Perform integration testing
1.3.4.1.1.4. Perform acceptance testing
1.3.4.1.1.4.1. Perform load testing (if needed)
1.3.4.1.1.4.2. Perform connectivity testing (if needed)
1.3.4.1.1.5. Obtain signoff from the testing team and end users
1.3.4.1.1.6. Note and communicate the customizations needed
1.3.4.1.1.7. Signoff test plan for vendor
1.3.4.1.2. Mobile frontend testing
1.3.4.1.2.1. Verify design and functionality
1.3.4.1.2.2. Perform unit testing
1.3.4.1.2.3. Perform integration testing
1.3.4.1.2.4. Perform acceptance testing
1.3.4.1.2.4.1. Perform load testing (if needed)
1.3.4.1.2.4.2. Perform connectivity testing (if needed)
1.3.4.1.2.5. Obtain signoff from the testing team and end users
1.3.4.1.2.6. Note and communicate the customizations needed
1.3.4.1.2.7. Signoff test plan for vendor
1.3.4.2. SQL database testing
1.3.4.2.1. Verify design/ data elements
1.3.4.2.2. Verify the relationships
1.3.4.2.3. Perform integration testing
1.3.4.2.4. Perform User acceptance testing
1.3.4.2.4.1. Acceptance testing in terms of load
1.3.4.2.4.2. Acceptance testing in terms of integrity etc
1.3.4.2.5. Obtain user signoff
1.3.4.3. Interface
Page18
1.3.4.3.1. Verify design and functionality
19. 1.3.4.3.2. Perform Integration Testing
1.3.4.3.3. Perform User Acceptance Testing
1.3.4.3.4. Obtain signoff from the testing team and end users
1.3.4.3.5. Note and communicate the customizations needed
1.3.4.3.6. Signoff test plan for vendor
1.3.4.4. Reports
1.3.4.4.1. Verify design and functionality
1.3.4.4.2. Perform Integration test
1.3.4.4.3. Perform User Acceptance Testing
1.3.4.4.4. Obtain signoff from the testing team and end users
1.3.4.4.5. Note and communicate the customizations needed
1.3.4.4.6. Signoff test plan for vendor
1.4. Test runs (TAVARI PVT. LTD)
1.4.1. Create system documentation
1.4.1.1. Assemble functional specification document
1.4.1.2. Assemble technical specification documents
1.4.1.3. Develop system flowcharts
1.4.1.4. Make proper documentation for the source code (in form of comments etc)
1.4.1.5. Deliver the source code
1.4.1.6. Complete system documentation manual
1.4.1.7. Get the document created by respective user and technical expert
1.4.1.8. Rework and baseline the changes that are suggested in system manual
1.4.2. Create test run materials
1.4.2.1. Assemble functional specifications
1.4.2.2. Develop “As Is” and “To be” documentations
1.4.2.3. Update business process
1.4.2.3.1. Write new business process
1.4.2.3.2. Obtain user signoff
1.4.2.4. Complete system documentation manual
1.4.2.5. Get the document created by respective user and technical expert
1.4.2.6. Rework and baseline the changes that are suggested in system manual
1.5. Project closure (TAVARI PVT. LTD)
1.5.1. Closure of project
1.5.2. Closure of contract with the vendor
1.5.3. Final project backup
1.5.4. Project review and lessons learnt documented
1.5.5. Final project signoff
Page19
1.6. Post project (TAVARI PVT. LTD)
20. 1.6.1. Post project maintenance
1.6.1.1. Verify the project functionality
1.6.1.2. Verify the acceptance functionality
1.6.2. Regular update/ patches
1.6.2.1. Verify the project versions of software update
1.6.2.2. Check and update the software installed
1.6.2.3. Make changes and update the software
1.6.2.4. Make required changes to custom code (if necessary) for each update of the software
Page20
21. Detail schedule for implementation of dart
project
The timeline for the project and present completion status of the project is as follows:
Serial No Task Name Start Date End Date Days Prev. Task % done Assigned To
Design of web 08/16/11 08/23/11 6 100% debashish bagg
application
1 Interface
Front End 08/16/11 08/17/11 2 100%
Interface
2 specification
SQL Database 08/18/11 08/19/11 2 2 100%
3 specification
4 Interfaces 08/18/11 08/22/11 3 2, 3FF 100%
5 Reports 08/23/11 08/23/11 1 2, 4FF +1 day 100%
6 Procurement 08/26/11 10/27/11 45 60% abhinav kamal
Planning 08/26/11 08/26/11 1 1FS +2 days 100%
7 software needs
Float the design 08/29/11 08/31/11 3 7 100%
specification to
respective
8 software vendors
Get quotation 09/01/11 09/05/11 3 8FF +3 days 100%
from software
9 providers
Compare the 09/06/11 09/06/11 0.5 9 100%
10 quotations
Take an 09/07/11 09/07/11 0.5 10 100%
decision of which
vendor to be
11 accepted
12 vendor visit 09/08/11 09/08/11 1 11 100%
Communicate 09/09/11 10/27/11 35 11FS +1 day 50%
to get the software
on board and start
with
13 customization
14 Customization 11/01/11 11/03/11 3 debashish bagg
Installation of 11/01/11 11/01/11 1 6FS +2 days
15 software
Initial testing 11/02/11 11/02/11 1.5 15
and validation of
the software and
16 its features
Implement the 11/03/11 11/03/11 1.5 16
required
17 customization
Final testing 11/02/11 11/03/11 2 17FF
Page21
18 and validation of
22. the software and
its features
19 Test runs 08/24/11 09/09/11 13 100% abhinav Kamal
Create system 08/24/11 08/30/11 5 1 100%
20 documentation
Create test run 09/05/11 09/09/11 5 20FS +3 days 100%
21 materials
22 Project closure 11/04/11 11/10/11 5 debashish bagg
Closure of 11/04/11 11/04/11 1 14
23 project
Closure of 11/07/11 11/08/11 2 23
contract with the
24 vendor
Final project 11/04/11 11/07/11 2 18
25 backup
Project review 11/09/11 11/09/11 1.5 24, 25
and lessons learn
26 documented
Final project 11/10/11 11/10/11 1 26
27 signoff
28 Post project 11/11/11 11/11/11 1 abhinav kamal
Post project 11/11/11 11/11/11 1 22
29 maintenance
Regular update/
30 patches
Page22
24. Software Project Management Final Project Report
Human Resource Allocation Plan
Roles and Responsibilities
The roles and responsibilities for the Software Upgrade Project are essential to project success. All
team members must clearly understand their roles and responsibilities in order to successfully perform their
portion of the project. For the Software Upgrade Project the following project team roles and responsibilities
have been established:
Project Manager (PM) (1 position):
PM is responsible for the overall success of the Software DART Project. The PM must authorize
and approve all project expenditures. The PM is also responsible for approving that work activities meet
established acceptability criteria and fall within acceptable variances. The PM will be responsible for
reporting project status in accordance with the communications management plan. The PM will evaluate the
performance of all project team members and communicate their performance to functional managers. The
PM is also responsible for acquiring human resources for the project through coordination with functional
managers. The PM must possess the following skills: leadership/management, budgeting, scheduling, and
effective communication.
Design Engineer (DE) (1 position):
DE is responsible for gathering coding requirements for the Software DART Project. The DE is
responsible for all upgrade design, coding, and testing of the upgraded software. The DEs will assist the
implementation lead in the distribution and monitoring of the software upgrades throughout the network
infrastructure. The DE will be responsible for timely status reporting to the PM as required by the
communications management plan. The DEs may not authorize any project expenditures nor allocate any
resources without PM approval.
Implementation Manager (IM) (1 position):
The IM is responsible for the distribution, implementation, and monitoring of the new software
upgrade. The IM is responsible for working with the DE to ensure all coding on new software conforms
with organizational security regulations. The IM is responsible for coordination outage windows with each
department to facilitate the rollout of the software upgrades with minimal/no disturbance to operations. The
24
IM will report status to the PM in accordance with the project‟s communications management plan.
Page
25. The following RACI chart shows the relationship between project tasks and team members. Any
proposed changes to project responsibilities must be reviewed and approved by the project manager.
Changes will be proposed in accordance with the project‟s change control process. As changes are made all
project documents will be updated and redistributed accordingly.
Project Manager Design Engineers Implementation Manager
Design of web application Interface A R R
Procurement/ Outsourcing A R C
Customization A R
Software Testing A R C
Implementation A C R
Project Closure A A C
Post closure Activities A A I
Key:
R – Responsible for completing the work
A – Accountable for ensuring task completion/sign off
C – Consulted before any decisions are made
I – Informed of when an action/decision has been made
Page25
26. Risk Management
There may several risks involved during or after the completion of this project. Those risks need to
be identified and managed in order to make the project a success.
Risk Identification
Risk associated with this project can be categorized under following four heads:
People risk:
o Risk 1: Acceptance from the customers for whom the application is being designed and
implemented in the first place
o Risk 2: Finding appropriate coders for coding the back-end functions to be performed by the
system.
o Risk 3: Lack of inputs from the team members during the planning, execution and
implementation of the project
Technological risk:
o Risk 4: Technical glitches faced by users while taking the test
o Risk 5: Providing appropriate results to application user
o Risk 6: Migration of platform from facebook to other if the target customer moves on
Financial and Time risk:
o Risk 7: Completing the project within the budget
o Risk 8: Completing the project within allocated timeline
Other risk:
o Risk 9: Realizing the required MOV for the SHAMIANA‟s investment
Qualitative Risk Analysis
The above-identified risks have to prioritized, so that appropriate actions can be taken in case of occurrence
of those risks.
Probability Low Medium High
Impact
Low Risk 5 Risk 7, Risk 8 Risk 2, Risk 3
Page26
27. Medium Risk 9 Risk 4
High Risk 1, Risk 6
List of Prioritized Risks:
Ranking Potential Risk
1 Acceptance from the customers for whom the application is being designed and
implemented in the first place
2 Migration of platform from facebook to other if the target customer moves on
3 Technical glitches faced by users while taking the test
4 Finding appropriate coders for coding the back-end functions to be performed by the
system
5 Completion of the project with in allocated timeline
6 Completing the project within the budget
7 Migration of platform from facebook to other if the target customer moves on
8 Realizing the required MOV for the Institute‟s investment
9 Providing appropriate results to application user
Risk Response Planning
In order to manage the risks the following strategies and actions can be performed:
Risk Strategy Action
Acceptance from the customers Risk There has to be a specific research that has been
Mitigation done to actually zero down to a set of game that
would be developed. This part is taken by
SHAMIANA.
Appropriate results Risk Through testing each module
Avoidance
Technical glitches Risk Use familiar hardware, and software available
Avoidance
Page27
Finding appropriate coders Risk Approach the familiar coders or coders whose
28. Mitigation work is known.
Time and cost constraints Risk Follow the WBS strictly and keep some slack for
Mitigation the coding part,
For cost also estimation is done on task and
functional point basis .
Realizing the required MOV Risk Promote the application as in ways possible
Transference
Risk Monitoring and Control
The project team should be at all times aware of any of the above-identified risks and should follow
the actions as stated in the previous table. In addition, the team should keep an open mind and keep
identifying any other risks while the execution and or implementation phase of this project. For the newly
identified risks, the team members should follow the complete risk management process.
Page28
