Project Follow Up Importance Follow up keeps consistent

Project Follow Up

Importance • Follow up keeps consistent the various stages of the system life cycle. At each stage, the follow up checks that: 1. all what was asked at the previous stage has been performed, 2. no function outside of the scope has been introduced.

• 1. 2. 3. 4. The follow up makes sure that the system meets exactly all requirements of those who have designed it. In close connection with all the previous items, Cogenit insists on the follow up study to show the connection between: specifications, design documents, test deliverable.

• Depending upon its place in the project cycle, the follow up meets the following needs: • checking the deliverables, • identifying discrepancies and risks, • helping production of specification, design and test documents.

• After an adequate result has been achieved in the cyclical phase, the project enters the follow-up phase. In this phase, the project result is secured. What this means depends upon the type of project and on the agreements that have been made with the client or customer. For a research project, a final report would probably suffice; the development of a new product would require more follow-up.

• Most of the problems in the follow-up phase arise because no clear agreements were made between the customer or client and the project team at the beginning of the project. The following are among the points that should be taken into consideration:

• • • How long should the follow-up last? What does the follow-up entail? How quickly must errors be repaired? Is there a guarantee on the project result? Who is responsible for bugs that are found after the project? Should documentation be delivered along with the project result? Will the users require training, schooling or both? Who is responsible for updates? Who will own the code, and who will be authorised to change it? Who will pay for the above-mentioned points?

• It is important to realise that a project organisation is focused on temporary activities and is therefore not focused on offering (lengthy) support for the software that they have developed. Other means of support must be found for the longer term. Special (commercial) organisations exist for managing software, offering helpdesk support, trainings, server administration, application administration and similar services. These organisations are likely to be (too) expensive for small nonprofit initiatives. • Another alternative for securing the continuity of the software is to make it open-source. For this solution, an organisation is established to allow a group of developers and users to maintain and support the software.

• • • Activities in the follow-up phase Report on the control factors of the project Compile and submit final statement. Dissolve team. Transfer to the administrative organisation.

• • • Result of the follow-up phase Project statement Transfer documents Operations Project leader Team members System administrator Decisions/Approval Project leader Client Current or potential customer

Managing Follow Up Items • What are Follow Up Items? • Follow up items are anything that the project manager has to remember to follow up on. These can be: • Issues - raised by the customer or the team members. • Action Items - identified during meetings • To Do List Items - identified by the project manager during personal planning sessions • Administrative Tasks - assigned by management • Or anything else - that must be remembered and fit into the project manager's already crowded day

• How to manage Follow Up Items • Here are some considerations that can simplify the management of Follow Up Items. • Just one list. – Put all follow up items on the same list regardless of their type or source. – Juggling multiple lists is not "simple". • Make it quick and simple to add and edit items. – Don't use separate edit and list views. Shifting modes distracts from immediacy and quickness. – A simple spreadsheet-like view is best.

• Minimize forms and fields. – Don't create separate fields for everything that "might" be useful. Re-use fields where convenient. (For example, keep status notes in the resolution field. ) – Just one description field. Don't have both brief and long descriptions. – Refer to other documentation, don't repeat it. The long description is just another summary of the real description that was (or should have been) published elsewhere. – Define only the necessary reports/views. • One for each project and one for all projects. • Any required custom reports, such as "Issue Tracking" (which is just another Follow Up report with non-issues hidden). • .

• Adjust tracking rules based on need. Don't use the most restrictive rules for all types of follow up items. – Flag special items with the "Category" field. For example, labeling an item as category "Issue" is enough of a reminder to record the final resolution and to keep a history for reporting purposes. – Leave fields blank unless it serves a purpose. – Don't bother to record a resolution just to "be consistent". – Delete follow up items when you are done with them. Only keep history when needed