1. Information system analysis and design
Dr. Dina Tbaishat

2. Recap
Last lecture we learnt how to write the requirements document, according to the IEEE standard
Today we shall continue on discussing a new topic related to project management
For projects and systems’ development to succeed, they must be well managed and supervised

3. Project management - Introduction
Project management is needed since there are always budget and schedule constraints
Project managers should plan and schedule the project, they should also make sure projects are carried out according to the required standards
The project manager’s job description varies according to the product type and to the organization itself
The main responsibilities of a project manager are:

4. Management activities
According to Sommerville (2001) these are:
Proposal writing: to describe the objectives, how it will be developed, usually includes costs / schedule estimates. This is a task acquired by experience
Project planning and scheduling: identifying activities, milestones and deliverables. Critical Path Analysis is one way for planning and scheduling, which shall be discussed in detail next lecture

5. Project costing: determine how much of the budget is needed to complete the project. Costs include all required resources
Project monitoring and reviews: keeping track of the project, is it going according to the schedule? Within the costs? During a project, reviews take place by “reviewing overall progress and technical development of the project and considering the project’s status against the aims of the organization commissioning the software” (Sommerville, 2001)  accommodating new changes emerging within the organization

6. Personnel selection and evaluation: choosing staff to work in the project, the selection should not be always ideal for the following reasons:
Low budget
Staff with appropriate experience may not be available
Might want to work on developing employees’ skills
Report writing and presentations: to the client. Should write concise and coherent document explaining details of the project

7. Project planning Planning well for a project avoids failure
Project planning is an iterative process that ends only when the project ends
The plan must be regularly reviewed
There are different types of plans that managers can draw up, these are:
Quality plan: the standards that will be used in the project
Validation plan: the methods, resources and schedule for system validation (testing)

8. Configuration management plan: process for establishing and maintaining consistency of a product's performance, requirements, etc… used in large complex systems such as weapon systems
Maintenance plan: predict maintenance costs and effort
Staff development plan: how to develop staff skills and experience
According to Sommerville (2001), most plans should include the following sections:

9. Introduction: objectives
Project organization: organizing the team, their roles
Risk analysis: possible risks, their probabilities and management (to be discussed in more detail next lecture)
HW and SW resource requirements
Work breakdown: breakdown of project into activities
Project schedule: dependencies between activities
Monitoring and reposting mechanisms: what reports to produce

10. Milestones and deliverables
Milestone: an end point of a process activity, where there should be a formal output (such as a report)
Reports do not need to be large, only to present the achievement of a project activity
Deliverable: a project result to be delivered to the customer
Usually delivered at the end of major stages such as design
“Deliverables are usually milestones but milestones need not be deliverables” (Sommerville, 2001)

11. Work Breakdown Structure (WBS)
This is a method that helps in identifying tasks within a project. This in turn helps later when using the network method, hence finding the critical path
Decomposing big tasks into their component smaller tasks, when reaching an appropriate level of detail, stop decomposing
Take into consideration:

12. The splitting of major tasks should be logical
It should be possible to test objectively when the work is complete
At the lowest level the work elements should be well defined tasks for one individual to perform within a reasonable period – say from a day to a week

13. This is an example that is taken from (Open University, 2012):

14. So the previous WBS shows the first step, trying to decompose the project objective “refurbish hospital ward” into major “packages’’ of work in logical way. The next step however is to decompose each work “package” into some components tasks as follows:

15. After the tasks were identified by the WBS, it is time to list them and put them in order according to “priorities”
It is also important to determine which tasks need to finish before other tasks can begin (predecessor)
So, some tasks must be done before others can start, for example, is it not possible to remove furnishings (beds, lockers, chairs, etc…) until there are no patients using them.
Usually, early tasks don’t have predecessors
The list created in the next table on the following slide may be sufficient, but it’s always better to proceed to graphical form

17. From here, how do we draw the network
From here, how do we draw the network??? This is to be learnt next lecture !

18. References
Open University. (2011). Team work in distributed environment: Project planning and scheduling, [Lecture notes]
Sommerville, I. (2001). Software Engineering. UK: Addison Wesley