IS2802 Introduction to Multimedia Applications for BusinessLecture 10: Web Project ManagementRob Gleasure

R.Gleasure@ucc.ie

www.robgleasure.com

Lecture Outline

When projects fail When projects succeed Harsh truths Project management Agility Testing and client involvement

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

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

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

What makes up project management? A conventional view... The Project Charter

The Work Breakdown Structure (WBS)

The Project Schedule

The Project Budget

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?

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

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

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?

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?

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 …

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

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.

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)

The Waterfall Approach

Taken from http://thenuzan.blogspot.ie/2014/09/sdlc.html

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

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 circumstances

Agility View of SDLC

Taken from http://zambzee.com/home/?page_id=190

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

Agile planning

Business people decide about Scope Priority Composition of releases Date of releases

Technical people decide about Estimates Consequences Process Detailed Scheduling

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

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

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…

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’

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

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.

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.

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’

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

Exam marking

Mark Criteria

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

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

Exam topics

JavaScript

Loops, Functions, and the Document Object Model

Validation and debugging

JQuery

Cookies

Project management

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