|
|
|---|---|
|
|
Version 1.01 Edition 1
Revision History
Table Of Contents This document will provide policies and guidelines that seek to address the following areas: Chain of Command
Purpose The purpose of this policy is to formalize the flow of information inside the team. This will provide the managers of the various sub-groups with a complete picture of the work going in and out of their sub-group. It will also ensure that the Team Leader is only given information once, rather than hearing it from many different sources. Execution The chain of command is fairly simple, and follows the team's structure closely, with only a few variations. The Development and Quality Assurance sub-groups are far more autonomous than the Publishing Team sub-group, who will be under the direct supervision of the Team Leader. All "normal" information (rather than issues that come under Conflict Resolution) generated at the sub-group level will first go to the manager of that sub-group. He/She will determine whether or not the issue is of significance outside of that subgroup, and if not, deal with it internally. Assuming that it is, the manager is responsible for finding all relevant information (and ensuring that he/she understands it fully) before bringing the issue up at a management meeting. If the issue is important of course, it would be brought up via e-mail much sooner than the next meeting. Day to day inter-sub-group communication (that follows written processes) does not require notifying the the Team Leader, but should still be performed trough the managers of the sub-groups other than the .
Purpose The purpose of this policy is merely to explain how the lifecycle of a piece of work proceeds. Specific processes on work creation, testing, etc. will be defined within the individual subgroups concerned, for example Quality Assurance will defined their own procedures regarding what happens when particular sorts of work arrive in their work domain. Execution All work is first checked to a reasonable degree by the creators of the work, using techniques such as peer review process and so on. Following this, the work is passed on to Quality Assurance, by the manager of the sub-group that created the work. For example, if a build of the application was created only the Project Architect can sign the build over to Quality Assurance for review. This is aimed at reducing the amount of work that Quality Assurance have to do to the minimum, thus ensuring that the standard of their work remains top notch. After reviewing the work, Quality Assurance will decide whether or not the work needs to be fixed. Assuming it isn't the work is then passed on to the Team Leader who is responsible for what happens to the work next. If the work is not satisfactory, it will be handed back to the sub-group manager, who will revise the work according to the notes obtained from Quality Assurance explaining what the problems with the work are. It is anticipated that eventually a java applet will be put in place in order to reduce the amount of administrative overhead in this area. Such an applet would include details of what sort of work was under review, where the relevant files can be found in the repository. The applet would also notify the QA team that a new task had been given to them via e-mail.
Purpose The repository is eventually to be used for all Team Synergy work. This currently includes source code and deliverable documents, but the web site and applet source code will be progressively added to the repository as time permits. It is Team Synergy's goal to have all work residing in the repository by the middle of the year.
Purpose Conflict resolution is a big issue, so Team Synergy have tried to narrow it down to three areas that we feel are relevant to the scope of our operations. It is Team Synergy's goal not only to ensure that we produce a high quality product, but also to ensure that all team members enjoy their time spent with the team. To this end, Team Synergy has invested time to ensure that there is a well defined set of polices that the team. One of the Team Leader's primary tasks will be ensuring that these polices are adhered to. These policies are listed below: Personal Conflicts This was included as Team Synergy believe the more that can be solve inside the group the better. These conflicts should at first be resolved at the lowest level possible. For example if two application engineers are having a non-productive shouting match, the Project Architect should try to resolve the issue. If this is impossible, the matter would be passed on to the Team Leader, who would in turn attempt to resolve the issue. In this fails, then the matter would be out of Team Synergy's hands, and directed to higher powers. If the said Application Engineer was having a conflict with the Project Architect, the matter would also be directed to the Team Leader, and then to higher powers. And obviously if there was a problem between the Team Leader and another member of the team that could not easily be resolved, then this matter would go straight t higher powers. Bastardization This is another important issue in the eyes of Team Synergy management. Bastardization is completely unacceptable, and if managers will be watched closely by the Team Leader to ensure that no one individual is receiving unfair treatment, or being singled out for ridicule. If a member of a sub-group is not producing work that the manager of that sub-group considers to be satisfactory, then ridiculing them in front of the sub-group is not going to solve anything. This will no doubt make the situation worse. Unfair work allocation This is probably the biggest problem that Team Synergy's conflict resolution strategies will need to be used for. The Team Leader will constantly monitor work logs to ensure that no one individual is receiving an disproportionate amount of work to do. If a trend is appearing the manager of the responsible sub-group will be asked to explain the circumstances that caused the situation to arise in the first place. If a member of the team feels that they have dealt an unfair work load, they are encouraged to try to resolve the issue with their manager first. If this is unproductive, then the said member should seek help from the Team Leader. If the Team Leader doesn't resolve the issue satisfactorily then the team member should discuss the matter with higher powers outside of Team Synergy.
Purpose The purpose of Team Synergy's progress review policy is to provide some guidelines to the management team on how to evaluate their performance for a given time period. Execution This process has two components to it, these will be dealt with separately below: Lessons learned This process involves statistical as well as subjective analysis of past work logs, task allocations, milestones, etc. The idea of this is that the management team will become better estimators of time requirements which should lead to better planning. This in turn should lead to the rank and file members of the team being better informed about how much work they will be expected to do over the next week/fortnight, etc. Risk Analysis For all tasks that Team Synergy consider to have a "significant" risk value shall have risk resolution plans in place. |
