Jan 26th, 2015 at 11:14 AM

Initial Study of Software Project Documentation

Contents

1. Introduction 2. Project Objectives 2.1 Goals and Objectives 2.2 Critical Success Factors 3. Scope 3.1 Organisational Scope 3.2 Logical Scope 3.3 Temporal Scope/Phasing 3.4 Related Projects 3.5 Out of Scope 4. Risks, Constraints and Assumptions 4.1 Risk Management Approach 4.2 Risks 4.3 Constraints 4.4 Assumptions 5. Project Organisation 5.1 Project Structure 5.2 Roles & Responsibi l i ties 6. Project Control 6.1 Issue Control 6.2 Change Control 6.3 Qual i ty Assurance 6.4 Financial Control 6.5 Information Management 7. Reporting 7.1 Reporting wi thin the Project Team 7.2 Management Reporting 8. Stakeholders 8.1 Identi fication and Analysis 8.2 Communication 9. Planning 9.1 Approach 9.2 Milestone Plan

1. Introduction:

Give some information on the Insti tution and the context of/background to the Project. How big is i t going to be and what areas will it cover? What approach wi l l be taken?

2. Project Objectives:

2.1 Goals and Objectives

An explanation of context of goals and objectives including some detai l on how they were arrived at and who was involved (can append any detai led information i f requi red). Objectives give detailed support to the Goals. An example is shown: Goals Objectives The system will improve job satisfaction levels wi thin the Insti tution It wi l l be a tool to help staff do the job they are paid for, not an added source of frustration It wi l l ease the administrative burden by al lowing users to work efficiently and effectively thus freeing time for those activi ties which add greater value Staff wi l l have readi ly accessible the day-to-day information they need to do their job It wi l l provide greater transparency for decision makers at al l levels

2.2 Critical Success Factors

How will you judge whether the objectives of the project have been met? Try to think of measurable improvements associated with each of the objectives. Even an apparently vague goal such as ‘ improve job satisfaction’ can have tangible and measurable objectives i f you are sufficiently speci fic about them. If you are not speci fic about objectives you may find it hard to assess the value of the project.

3. Scope:

3.1 Organisational Scope

Sets out how the organisation is going to approach the project including detai ls of any intention to secure the services of a supplier/partner. Broad explanation of how the project wi l l incorporate requi rements of the various stakeholders within the organisation. Also, any avai lable detai ls on to what extent, i f any, the organisation may be required to give access to external parties.

3.2 Logical Scope

Gives a high level overview when purchasing a system of the areas or processes covered by the project as well as any interfacing and infrastructure detai ls – when purchasing a system i t can be useful to final ise this as part of your Invi tation to Tender. An example would be key Student Administration processes wi thin a project scope – as detai led below: Student Administration Programme and Module Catalogue Qual i ty Procedures and Checks Enqui ries Appl ications and Admissions Clearing Houses Enrolment Student & Community Information Timetabling Assessment and Examinations Progression and Awards Graduation Leavers and Alumni Research Reporting to External Bodies Management Information Production

3.3 Temporal Scope/Phasing

This should give an overview of the time constraints and mi lestones, including start and end dates where these are known. It wi l l be helpful to break the project down into phases and identi fy what is in scope for each phase (even i f you can’ t yet set timescales for al l phases). You may need to think about: Processes Software Appl ications Hardware Locations Users Infrastructure Interfaces Testing Phase: Phase Title Scope: Dates/Duration: Del iverables: Users/Locations:

3.4 Related Projects

List any related projects (if any) wi th details of expected completion dates and any potential for overlap of requi rements for support resource – as this could have ‘knock-on’ effects re timescales, etc. Also flag any other potential impacts and identify, where possible, anyrequi rement for output from the other projects.Projects Expected Completion Workflow Mapping: a team is mapping the current processes relating to student administration. There is a potential confl ict wi th the system selection project as some members of the workflow team will be required to contribute their process knowledge to the system selection project. April 2014

3.5 Out of Scope

If any potentially related areas have been defined as out of scope i t is worth making this explicit e.g. you are implementing a system to undertake course timetabl ing but not exam timetabl ing or you are implementing a personnel system that does not include payroll .

4. Risks, Constraints and Assumptions

4.1 Risk Management Approach

A description of the approach you are taking can be included here, including responsibi l i ties for recording risks and implementing appropriate risk management strategies, as wel l as communicating such information to the Project Steering Board. A ful ler consideration of Risk Management is given in the Risk Management infoKi t.

4.2 Risks

In terms of recording identified risks, actions to be taken and early warning signs we recommend that you use the JISC infoNet Risk Assessment template. This is because you wi l l need to review and update the risk management document throughout the course of the project. You may however wish to summarise the main risks here or paste in detai ls from the risk template to give an overview of the risks perceived at the start of the project.

4.3 Constraints

This section summarises any constraints that affect the scope of your project or how you carry out the project e.g. project staff are only avai lable during the summer vacation, new system must interface wi th another system, requi rements of external bodies affect the extent to which you can al ter a process etc.

4.4 Assumptions

This is a list of assumptions on which the initial project framework and plan are based. The JISC infoNet Project Management infoKi t discusses the sort of assumptions that can cause issues i f not clari fied ini tial ly. Examples may relate to many areas including: provision of infrastructure, IT support, resource avai labi l i ty, communication, training, staff development,working arrangements (and flexibili ty) and user expertise. Take particular care in defining what is expected of people outside the project team. Project Assumption

5. Project Organisation

5.1 Project Structure

It may be helpful to show the project structure as a diagram – an example is given below:

5.2 Roles & Responsibilities

Di rect resource requi rements for the project should be detai led here. This should indicate the numbers and types of staff and thei r estimated commi tment to the project. We recommend using the JISC infoNet Roles and Responsibi l i ties template to record the detai l of roles and responsibilities as this may need regular updating during the course of the project. A summary of that document could be pasted in or appended to this Project Ini tiation Document. Project Role Number of People Days per Week Total Days for the Project

6. Project Control

How will the project be moni tored and control led on a day-to-day basis? How wi l l i t be evaluated? What methods wi l l be used to faci l i tate effective team working?

6.1 Issue Control

This section should define how the project team is going to deal with issues. Project issues must be identi fied, priori tised and deal t wi th swiftly to ensure that dependent activities are not affected. An issues log is an ideal way of keeping a record of issues as they arise and also recording how they are resolved. The JISC infoNet Project Management infoKi t provides a template Project Controls Database (add url ) that contains an issue log.

6.2 Change Control

The change control section documents what happens when someone proposes a modi fication to the planned output of the project. Each Change Request should be documented (including ini tiator, reasons and a description of the change requi red) and evaluated in terms of i ts impact.The appropriate actions required to resolve the requested change can then be determined. Change Requests can then be deal t wi th by the Project Steering Board, or other agreed person/group supporting the project. The JISC infoNet Project Management infoKi t provides a template Change Request form and template control log.

6.3 Qual i ty Assurance

What Quality Assurance measures are planned? Who will evaluate qual i ty and when? Will an external assessor be appointed? How will deliverables be tested and formal ly signed off? Is there an agreed User Acceptance Testing mechanism?

6.4 Financial Control

Outl ine responsibilities for the control of expendi ture and budgets. You may wish to attach the project budget as an appendix to this document but you will need to consider the confidentiality of such information especially where you are working wi th thi rd parties.

6.5 Information Management

How is relevant project information to be held? There are issues here regarding qual i ty and availability of information – it may be useful to put in place a central reposi tory or project l ibrary of relevant information and ini tiate a cul ture of sharing information throughout the project. The importance of information management should not be underestimated – i t can be a critical contributory factor to successful achievement of project goals.

7. Reporting

7.1 Reporting wi thin the Project Team

This section should define how and when the project team members report progress.

7.2 Management Reporting

This section should define how and when the Project Manager reports to the Sponsor and/or Steering Board.

8. Stakeholders

8.1 Identi fication and Analysis

It is useful at this stage not only to identi fy your key stakeholders but to undertake some analysis of what thei r perceptions of your project are likely to be. This will help to show that you are aware of thei r views and will help you focus communications. We recommend that you use the JISC infoNet Stakeholder Analysis template for this purpose as the document may need regular updating. You may wish to summarise the key stakeholders here or append your analysis.

8.2 Communication

Appropriate two-way communication wi th stakeholders is crucial to the success of the project. This matrix gives examples of how you may start to think about the interested parties and the suggested communication channels to be used for each group. Stakeholders Expected Communications Frequency Media Project Steering Board Status reporting Issues reporting In line with Project mi lestones Dependent on timing and priority General ly, formal reports to be fol lowed up by face-to-face contact where appropriate Project Team Documentation and standards Project knowledge Internal communications In line wi th plan Ad hoc as necessary Central repository, managed by project administration Group e-mai l Team meetings Stakeholders Expected Communications Frequency Media Admin User Representatives Informal communication of progress Discussion of issues Respond to issues raised In line wi th plan Ad hoc on demand Group e-mai l , from project office Formal reports plus informal communication wi th Project Team

9. Planning

9.1 Approach

This section should outl ine your approach to project planning. JISC infoNet advocates the ‘Sl iding Planning Window’ approach as described in the Project Management infoKi t.

9.2 Milestone Plan

Insert a copy of the initial outline plan or summarise the key milestones and dates.