1. Copyright © 2001 Bolton Institute Faculty of Technology - 34.4 Multimedia Integration and Applications Lecture 9: Production Management Damien Markey

2. Copyright © 2001 Bolton Institute Faculty of Technology - 34.4 Multimedia Integration and Applications Lecture 9: Production Management Staging/Production and Live servers Communication Plan The internal project site The client facing demo site Why monitor a project? “Scope Creep” Change Management

3. Copyright © 2001 Bolton Institute Faculty of Technology - 34.4 Multimedia Integration and Applications Staging/Production and Live servers Staging/Production servers are the servers that are used during the main build Live servers are the end platform the site should be deployed on They should be as identical as possible in terms of hardware and software Production servers have to be tightly controlled to ensure that only content to be deployed is stored on them

4. Copyright © 2001 Bolton Institute Faculty of Technology - 34.4 Multimedia Integration and Applications Staging/Production and Live servers - 2 An example of a production site maintenance issue: –It is common for code to be created and then discarded during a build. This code could also be used elsewhere in the site, by a different team than the original authors. If the code is discarded the other teams pages will not work! Logs should be kept of –Where common code is kept –Who is using it –Where it is used

5. Copyright © 2001 Bolton Institute Faculty of Technology - 34.4 Multimedia Integration and Applications Staging/Production and Live servers - 3 It is also common for several projects to use the same production server A “Clean” build must be taken when final production testing is finished –A clean build contains only the code and other assets needed to operate the site. It does not contain dummy data, testing data or out of date production code This can then be delivered to the live server for final testing Never ever use a live server for production!!!

6. Copyright © 2001 Bolton Institute Faculty of Technology - 34.4 Multimedia Integration and Applications Communication Issues A common problem with most development projects are communication issues These can be present in a number of ways –Lack of communication “I thought you knew where XXX was” –No agreed, and communicated, standards “I thought the graphics were all JPGs” –Communication leakage Designer: “The client told me to make the change!”

7. Copyright © 2001 Bolton Institute Faculty of Technology - 34.4 Multimedia Integration and Applications Communication Plan These can be addressed by –Communicating basic project information See project site –Agreeing suitable communication paths between team members –Defining task responsibilities for teams and team members –Defining reporting responsibilities for teams and team members Who reports, to whom and when

8. Copyright © 2001 Bolton Institute Faculty of Technology - 34.4 Multimedia Integration and Applications Communication Plan -2 Sign off responsibilities should also be agreed here –So that everyone knows who has final sign off on a project handover object Communication paths are the definitions of which team members should be in communication with each other Team members can be internal or external and include the client They are commonly detailed in a communication plan and can include a communication diagram

9. Copyright © 2001 Bolton Institute Faculty of Technology - 34.4 Multimedia Integration and Applications

10. Copyright © 2001 Bolton Institute Faculty of Technology - 34.4 Multimedia Integration and Applications The Internal project site As an aid to communication you should have a central resource for information This is commonly the “Project site” Common contents include –Names and contact details for team members –Deadline dates –Description of deliverables –Responsibilities of team members

11. Copyright © 2001 Bolton Institute Faculty of Technology - 34.4 Multimedia Integration and Applications Client Facing Demo Site The client will want to see progress of their site The team will need to monitor the progress of the build This can be achieved through two methods: 1.Providing the client with access to the production server 2.Providing the client with an enhanced protosite at key stages throughout the build

12. Copyright © 2001 Bolton Institute Faculty of Technology - 34.4 Multimedia Integration and Applications Client Access to Production Server Disadvantage: –The server will not always be available as the production team will be constantly changing it Advantage: –The client sees an “up-to-the-minute” site The clients expectations of what they are seeing has to be set early on –Client “Can’t we go live as the site looks finished?”

13. Copyright © 2001 Bolton Institute Faculty of Technology - 34.4 Multimedia Integration and Applications Enhanced Client Protosite Disadvantage: –Can be time and cost consuming to update and test a separate version of the site Advantage: –The client sees a controlled version of the site’s present condition with completed functionality –The client does not see lots of “Error 404” messages!

14. Copyright © 2001 Bolton Institute Faculty of Technology - 34.4 Multimedia Integration and Applications Why Monitor a Project? Without constant measuring of development progress, scope and budget the project will fail Items to check against –Progress Check progress of development tasks against estimates and plans –Budget If tasks durations, resources used or scope changes then the budget may change

15. Copyright © 2001 Bolton Institute Faculty of Technology - 34.4 Multimedia Integration and Applications Why Monitor a Project? -2 Scope –Any changes to the scope (by client or team) needs to be checked against the original scope and requirements

16. Copyright © 2001 Bolton Institute Faculty of Technology - 34.4 Multimedia Integration and Applications Scope Creep Scope creep happens when the developer commits to work that is beyond the original scope and requirements but does not amend the scope and/or requirements Changes will happen and can be accommodated –if agreed between the client and the developer –and the scope and requirements are amended See “Change management”

17. Copyright © 2001 Bolton Institute Faculty of Technology - 34.4 Multimedia Integration and Applications Scope Creep - 2 Scope creep can be gradual or it can be in large packets (it usually occurs in the former) Scope creep is a major cause of failed projects Common changes are –Additional features and functionality –Graphical changes –Increased Content changes –Increased Content (and conversion)

18. Copyright © 2001 Bolton Institute Faculty of Technology - 34.4 Multimedia Integration and Applications Change Management Changes will happen and are necessary due to changes in technology, audience and environment Change must be managed otherwise “Scope creep” occurs If the change is client requested then the effect of the change must be measured, quantified and communicated to client (in terms of time, cost and impact to project plan)

19. Copyright © 2001 Bolton Institute Faculty of Technology - 34.4 Multimedia Integration and Applications Change Management - 2 For every requested change (either internal or external) –Measure the effect in terms of Resources used Skills required Effect on –Project Plan, –deadlines –and budget

20. Copyright © 2001 Bolton Institute Faculty of Technology - 34.4 Multimedia Integration and Applications Change Management – 3 The impact and cost are then, and only then, communicated to the client Only when client agrees to the above can the change be considered approved and the work commence