The Project Proposal

1. The Project Proposal

2. Summary of Project • No more that 350 words • The abstract can consist of a one-line summary of each of the other sections of the proposal.

3. Project Background • Setting the scene for the project, what is the background to this research • How does it fit into the context of Knowledge management/engineering – provide a couple of definitions of KM that support this research • How does it fit into the organisation culture context. • 6-8 references in this section • Don’t talk about your specific research in this section

4. Project Description • This is what my project is about, these is the organisation I will be doing it in and these are the tests I would like to do. • 2-3 references

5. Project Aim • This is the “thesis” of the project • Bloom’s Taxonomy Verbs • e.g. • “This research will measure how Web 2.0 tools can improve collaboration and knowledge sharing”.

6. Project Objectives • Between 3 and 6 • Explain the milestones in reaching your project Aim. • Look at existing approaches and measure new approach.

7. Evaluation Criteria • how you intend to implement and evaluate your research • What methods Quan/Qual • IEEE 829 Standard for Software Test Documentation. • ISO 9126 and ISO 14598 (which are standards on software evaluation)

8. Deliverables • Literature Review • Dissertation Document • Software (?) • Survey results on CD • . • . • .

9. Timeframes and Project Plan • Risk mitigation, monitoring and management

10. Risk Matrix

11. Risk Mitigation, Monitoring and Management • An effective strategy must consider three issues: • risk avoidance, • risk monitoring, and • risk management and contingency planning.

12. Risk Mitigation, Monitoring and Management • Example: • Assume that high staff turnover is noted as a project risk

13. Risk Mitigation • A proactive approach to risk avoidance is the best strategy. Develop a plan for risk mitigation. For example: assume that high staff turnover is noted as a project risk r1, some of the possible steps to be taken are these: • Meet with current staff to determine causes for turnover • Assume turnover will occur and develop techniques to ensure continuity when people leave. • Define a backup staff member for every critical technologies. • Double everyone’s salary

14. Risk Monitoring • As the project proceeds, the following factors can be monitored: • general attitude of team members based on project pressures, • the degree to which the team has jelled, • interpersonal relationship among team members, • availability of jobs within the company and outside it • As the project proceeds, risk monitoring activities commence. • In addition of these factors, the project manager should monitor the effectiveness of risk mitigation steps. • Project manager monitors factors that may provide an indication of whether the risk is becoming more or less likely

15. Risk Management • Contingency Planning • Assumes that mitigation efforts have failed and that the risk has become a reality • Continuing the example, the project is well underway and a number of people announce that they will be leaving • If the mitigation strategy has been followed, backup is available, information is documented and knowledge has been dispersed across the team

16. TYPES OF RISKS • Discuss project-based risks only • These are NOT risks; • I might get sick in the middle of my project • I might get a promotion and be too busy in my job • My girlfriend/boyfriend might run off with my best friend • My dog might run away • My supervisor might now give me a lot of feedback

17. TYPES OF RISKS • These are risks; • My test audience might not help me • The tool I use might not fully match the requirements • I might not get the technology/software I need • I might not get a lot of responses from my survey • Problems might take longer to solve than I predicted

18. Technical and Non-Technical Resources Required • Access to people • PC / Laptop / PDA / etc. • Software Libraries

19. References • About 10-15 • In Harvard format