1. IS2802 Introduction to Multimedia Applications for Business Lecture 10: Web Project Management Rob Gleasure R.Gleasure@ucc.ie www.robgleasure.com

2. Lecture Outline When projects fail When projects succeed Harsh truths Project management Agility Testing and client involvement

3. Disclaimer! This is not intended to be a complete overview of project management – this is an introduction, presented within the perspective of small-to-medium web development projects

4. When Projects Fail Failure to align project with business objectives Poorly defined scope Unrealistic expectations Waning client enthusiasm Lack of project management Inability to move beyond individual and personality conflicts Politics

5. When Projects Succeed Fully committed client buy-in Well-defined project charter Strong project management The right mix of people Good communication and decision making structure Shared goals

6. What makes up project management? A conventional view... The Project Charter The Work Breakdown Structure (WBS) The Project Schedule The Project Budget

7. The project charter What exactly is the desired outcome?  What is the purpose of the site?  Who are the intended users?  When must it be completed?  Who else will be involved in the development? Does the answer to each of these questions tangible and realistic?

8. The work breakdown structure We now know the ultimate goal the client has for the project, so next we need to figure out how to go about achieving this goal First we identify all of the task categories, e.g. analysis of relevant extant client systems, scheduling, prototyping, aesthetic design, data design, implementation, testing and revision. Next we identify the subtasks involved in each of these task categories, and the sub-subtasks involved in those (and so on until we have the whole project broken down into indivisible tasks) Each task or subtask must have one deliverable, which all add up to the final deliverable, at which point the project is finished

9. The project schedule Once we know each of the tasks involved in the project, we must then estimate how long each of these will take, as well as any ancillary costs involved We may then start planning out the project according to a defined set of milestones (there may be several deliverables to one milestone, but if there are several milestones to one deliverable then your planning should be revisited)* Based upon this information, it should be possible to estimate a project completion date, as well as the amount of hours involved * These milestones also represent an excellent stopping point to get client feedback

10. The project schedule One issue which has to be factored in here, is that of risk You can’t foresee everything that will come up during a project. The more grey areas, the more opportunities for setbacks. Can any of these setbacks render the project no longer feasible? How much time exactly could they end up costing you?

11. The project budget Getting a deal does not necessarily mean you will make money (or at least not enough to make it worthwhile) 1. Get contract 2. …. 3. Profit! Based upon the estimated work hours, the risk of failure, the ancillary costs, and the proposed amount of money, is this project still desirable?

12. Harsh truths The bigger the project the greater the likelihood it will take longer and cost more than anticipated Lily pad syndrome No one likes to admit, or hear about, slow progress Problems  loss of enthusiasm  problems  loss of enthusiasm  problems  loss of enthusiasm  problems  loss of enthusiasm  problems  loss of enthusiasm  problems  loss of enthusiasm  problems  loss of enthusiasm  problems  loss of enthusiasm  problems  loss of enthusiasm …

13. Once upon a time: the SDLC and waterfall software development The SDLC describes the activities performed at each stage of a software development project. This involves six steps 1. Requirements Gathering and Analysis 2. Design 3. Development/Implementation 4. Testing 5. Implementation 6. Maintenance

14. Why use the SDLC It provides a standard generic framework that can be re-used and adjusted across multiple projects SDLC + project parameters  Plan Project parameters will include:  Scope,  Budget,  Duration This let’s us negotiate details with clients, spot problems early, regulate development, etc.

15. The Waterfall Approach The classic model of development is the waterfall model introduced by Royce in 1970 Each phase is completed before the next begins Idea of handover between phases, i.e. ‘waterfall’ Upstream changes may occur but only to address some emerging issues (you don’t aim for this to happen)

16. The Waterfall Approach Taken from http://thenuzan.blogspot.ie/2014/09/sdlc.html

17. Agile Approach To combat the high failure rates and growing dissatisfaction with software development approaches, in 2001 the ‘Agile Manifesto’ was introduced Agility is argued as a philosophy, not just a set of practices  Adaptation is preferred to prediction  Iteration is preferred to linearity  Working code is preferred to documentation

18. The 12 Principles of Agility 1. Customer satisfaction by rapid delivery of useful software 2. Welcome changing requirements, even late in development 3. Working software is delivered frequently (weeks rather than months) 4. Close, daily cooperation between business people and developers 5. Projects are built around motivated individuals, who should be trusted 6. Face-to-face conversation is the best form of communication (co-location) 7. Working software is the principal measure of progress 8. Sustainable development, able to maintain a constant pace 9. Continuous attention to technical excellence and good design 10. Simplicity—the art of maximizing the amount of work not done—is essential 11. Self-organizing teams 12. Regular adaptation to changing circumstance s

19. Agility View of SDLC Taken from http://zambzee.com/home/?page_id=190

20. Types of Agile Approach There are many different types of agile methodologies, e.g.  eXtreme Programming (XP)  Scrum  Dynamic Systems Development Method (DSDM)  Rational Unified Process (RUP) Of these, scrum and XP are arguably most common

21. Agile planning Business people decide about  Scope  Priority  Composition of releases  Date of releases Technical people decide about  Estimates  Consequences  Process  Detailed Scheduling

22. Agile coordination Daily standup meetings are used to manage this  15 minutes max  No sitting  Same time and place each day  Everyone quickly runs through what they did yesterday, what they will do today, and anything slowing them down

23. Designing, Coding, and Testing in XP Minimal design, especially early Single repository for code, everyone commits their code every day All code has unit tests More tests created as soon as a bug is found Code must pass all tests before it can be released

24. Advantages of Agile Reflects iterative nature of exploratory development Ability to following changing requirements means more chance of useful output Does not require estimation of tasks that may are poorly understood Little administrative overhead Value realised early – client is almost guaranteed to get something…

25. Prototyping and client involvement When you design websites for college work, you are given specifications, as well as a deadline, at which point you deliver the complete website and hope it is deemed to satisfy the requirements. Real-life web development is different – the longer you work on something that the client doesn’t want, the greater the cost of rework and/or risk of dissatisfaction.  Every time the customer signs off on something (either verbally or formally, depending on the nature of the project), everything up to that point becomes ‘safe’  think of this as concept ‘testing’

26. Prototyping and client involvement (see IS1805 lecture 7) There are two basic type of prototyping  Prototypes (discarded when full development begins) These are mockups to test a website at an abstract level, e.g. layout, colours, structure. Often these take the form of ‘paper prototypes’ or storyboard- style walkthroughs, although webpages/parts of webpages may also be coded up where necessary  Tracer bullets These are websites built with limited functionality, so that certain fundamental aspects of the site can be tested and issues investigated The code is used as a scaffold for the complete website

27. Sign off Early on (while you still have the ability to walk away no worse for wear), capture as much of the agreed upon requirements and scope as possible in writing and get the client to agree to it This is a lesson you will learn, one way or another If you can show at the end of a project that you delivered what you promised, when you promised it, within the estimated cost, there is no room for complaint. Without this explicit checklist, your client may feel (rightly or wrongly) that their expectations were not met.

28. Exam format Two questions, pick one (all worth equal marks) Essay style questions based on the issues around Web design we have discussed in class.  E.g. discuss a given statement, illustrate some implications of x, discuss the challenges of y, etc.

29. Exam technique Time management is vital! Make sure you have a plan regarding how you will spend time. This will save you the stress of trying to think this out during the exam.  E.g. you have 45 minutes for this half of the exam – one possible plan for this could be: 5 minutes at the beginning to decide on which question Then  5 minutes to plan out answer, including key points to make  30 minutes to write answer  5 minutes to read over answer 5 minutes at the end ‘spare’

30. Exam technique Do not go over time on one question and leave yourself short on another – two ‘good’ answers generally do better than one ‘excellent’ answer and one ‘ok’ answer Answer the question - marks are awarded for relevant points only. Each sentence should have a purpose, either making or reinforcing a point. Note - this is not creative writing, just get your point across clearly. E.g. if something is difficult to describe, draw a picture. When arguing, take a position but don’t be over zealous. You are trying to be persuasive, so you must show you have considered different perspectives

31. Exam marking MarkCriteria 70% + Evidence of further reading and original arguments Clear relationships between statements Proficiency in all learning objectives in the area 60% - 69% Competent answer which addressed topic in question Apparent and easy to follow line of argument 50% - 59% Shows a knowledge and understanding of the area Argument made but not well supported or easy to follow Knowledge replicated but no sense of broad understanding 40% - 49% Shows some knowledge without really addressing question Awareness of issues in isolation 39% or less Fails to adequately address the topic or answer the question

32. Answering Questions Sketch out your diagrams very quickly as roughwork if you’re not sure how to make them fit together Bring a pencil and eraser! Answer your best questions first Try and demonstrate both that you understand the phenomena and that your understanding has practical implications Use examples  Have these lined up as part of your revision where possible

33. Exam topics JavaScript Loops, Functions, and the Document Object Model Validation and debugging JQuery Cookies Project management

34. References and Further Reading Jeff Sutherland (2014). Scrum: A revolutionary approach to building teams, beating deadlines and boosting productivity, Random House, UK. Beck, K. (2004). Extreme Programming Explained: Embrace Change, Addison-Wesley The agile manifesto  http://agilemanifesto.org/ Fred Brooks  The mythical man month  No silver bullet