New Project Proposal
PROJECT NAME: Project type:
Bug tracking
Proposal Rev and Date:
0.1 12/11/06
Project Sponsor:
Yair ben ari
Project Manager:
Galit Daniel
Target Completion:
30/6/2007
Total Budget Est:
Project Overview: Project Objectives Statement: The goal of this project is to deliver BugRep to market in final form no later than 30/6/2007 while delivering to our customers the ability to report issues and bugs in company products assign programmers for bug fixes and track status of handling them.
Business Justification: Our company have released the 3rd product in a line of products. Bug reports are handled unofficially and it is getting difficult to track them. We need a dedicated software for handling these issues to enable better tracking of bug reports, and improving our service to customers. Should this project’s schedule be accelerated? Why? Definitely, since bug and issue reports are piling and managing them manually is getting out of control.
Key Stakeholders: At the moment only the development team of the product line, but in the future this product might also serve the helpdesk team, QA, and also management ( for tracking progress of handling issues, producing indicators ,etc. ) Related Projects: Add link from company web site (for example: "Customer Support")
Technology: What's involved? What technology risks? Technology wise we are planning on developing a web browser based interface for our clients to use directly to prevent deployment issues. The application will be based on J2EE technology using Spring framework as the main application framework. We're planning on using MySql or other open source DBMS. We have very little knowledge and experience with the technology involved which might be a risk. Major Risks: No prior knowledge of working with J2EE technology. Favoring open source technology ( Spring , Tomcat etc. ) with no guaranteed support. No prior knowledge in the problem domain. The company products are of different nature then this application.
November 15, 2006
Page 1
New Project Proposal Questions/items for further research before a full project would be approved and funded: Find out what the competitors are doing, what similar products are there. Look at client bug reports and find out the typical information supplied by customers when reporting bugs. Solicit the development team regarding type of information required by them for handling bugs.
Project Scope In Scope: Allowing customers a direct interface to report bugs. Allowing management an interface for tracking of bug handling process. Allowing assigning of developers to bug fixing tasks.
Out of Scope: Tracking of development tasks Tracking of other non development related project activities ( testing, requirements management etc.) New feature requests
Deliverables: A CD with user guide , a deployable jar / war file, source code.
Early Staffing Estimates Resources needed to investigate before project approval: a team of 4 people: 2 developers who will investigate technical aspects related to J2EE technologies. 2 business oriented people to investigate customer and developers needs and competing products. Resources Needed for Full Project (estimate): 5 people doing development + management + testing. FUNCTION: Developers
Skill level, specific experience, etc. One highly skilled developer preferably with prior experience in the field. 2 developers with basic skills. 1 graphic designer for the web interface.
FTE
Management
We'll need a product manager - preferably someone available full time. The PM will also define the acceptance tests together with the testing team
7
Testing and QA
A team of 1 – 2 of experienced testers. The team will aid the product manager in building and running the Acceptance tests. They'll also build the functional tests for the development team.
12
17
“Function” means the various functional groups needed on the project (e.g. marketing, sales, development, process experts, networking engineers, architects, etc.) November 15, 2006
Page 2
New Project Proposal “FTE” stands for “full time equivalent,” or the approximate number of man-hours divided by 8 hours per day. Gives managers an understanding of how many people from each function may be required.
Rough Project Timeline ** Phase:
0 – Proposal
1– Requirement gathering
2–
3–
4–
Design
Development
Testing
Review Date:
16/11/06
28/12/06
15/2/07
30/4/07
21/6/07
Range:
1 week
1 week
2 weeks
2 weeks
1 week
** As a small group does investigative work on alternatives, it should identify how a project timeline could play out – how the project would likely be broken down into phases, and of what rough duration. An early take at such a timeline during phase 0, before the idea is even approved, helps Management understand how the project would fit into the existing portfolio and resource allocation. The ‘range’ row is thus used to show uncertainty on the phase end dates. The proposal document can be updated all the way through the investigation/planning phase, until a full project plan and schedule exist, at which point these phaseend-dates would become solid. Related DocumentsExecutive Decision Record Description
Topic
Date
Approver
Ref / Link/Attachment
Executive Decision Record Decision Made (resource assignments, project funding, scope decisions, etc.)
The team can include a decision record to note critical decisions made regarding the project definition as well as decisions on whether to proceed with further work after each review.
November 15, 2006
Page 3
