We recently rolled out Team Foundation Server Work Item Tracking at work to a pilot project. During the discussions we were asked what did we want from pilot project and this made me think about how pilot projects are created and what are the expectations.
- There will be more direct visibility for code change due to various work items related to the project.
- We will be eliminating various different tracking systems (Clear quest, SR System, worksheets, Quality Center Defect module, etc) and will save time from having to do duplicate entries.
One of our biggest goal was to consolidate different tracking systems. We had more than 5 tools and each project also had their own little system like worksheet or share point issues log. We wanted to make sure our tool would fit all these needs.
We then put a plan together for this project to make sure we had a time line and also set expectations for the pilot team.
- Project X will start using this for TFS work item to track bugs, change requests and tasks.
- The pilot will last 4 weeks after which a decision will be made on the roll out process for other projects within the organization.
- Support will be provided during these 4 weeks for questions regarding process, tool, and technology.
- Feedback will be gathered via emails, surveys and interviews.
Feedback will be gathered during these 4 weeks around the following areas
- User guide and documentation
- Use of tool
- Technical adaptability
- Advantages and disadvantages
- Gaps in process within the tool
We will validate our hypothesis and present our reports to management
The data gathered during the pilot will be presented at the end of 4 weeks with our findings
If changes are proposed to workflow or tool, they will be presented to the steering committee to get approval for appropriate changes.