Reference no: EM133031552
QUAL11021 Projects in Practice - University of the West of Scotland
Project Planning And Control Using The Business Project Methodology And Software
Part A asks you to plan a project and follow the guidelines set out in the Business Project Management (BPM) methodology to create a BPM Specification (similar to a PMP or PID) for a real project. You should attempt this in groups of 4, 5 or 6; however you can accomplish it on your own if necessary.
Part B invites you (individually) to consider and demonstrate how to manage a project and how to use MS Project or equivalent software to monitor and control a project. At the end of the project you should report on the actual stages, progress, success, problems, outcomes and lessons of the project.
Part A
In the first part of the coursework you should work in small groups to plan and use the BPM approach (discussed in lectures) to organise a project that may involve many different stakeholders and a certain amount of complexity. In the early stages each member of the team may take on specific roles (eg Business Analyst, Planner, Researcher, Publicist, Project Manager) or you may share all the work, to explore and follow the method properly and produce the BPM Specification documentation (BPMS). You may use "Project in a Box" if you like.
The Start of the Project.
Each group decides upon a suitable project and prepares a definition of, and plan to carry out, the project. Each group must select a different project. The various plans, specifications and arrangements should be collected and documented in a BPM Specification (BPMS) (similar to a PMP or Project Initiation Document) and this report should contain all the necessary contents and level of detail explained in lectures and notes for the module. BPMS content headings are: Terms of Reference, Business Case, Feasibility and Risk Analysis, Plans. A complete list of the items to be included in this document is provided in the table below. Examples and templates of various forms and reports will also be given in the Moodle site for this module. You should create an overview Work Breakdown Structure and include this with this BPMS,
Part A - Documentation for the First Section
The following outline framework gives an idea of the main headings, contents and structure that you are expected to follow when writing the BPM Specification report and completing the first part of the assignment. You will most likely gather, analyse and record this information progressively over the first weeks and build the document(s) as you work on the project. It is expected, for example, that you will do most of the Terms of Reference in week 3, the Business Case in week 4, the
Feasibility study and Risk analysis in week 5, and the planning aspects in week 6. For project configuration management purposes two columns have been added that may help you to organize and then track updates and changes.
Project Management and the use of MSProject1or Equivalent
Part B invites you (individually) to explore and report on managing a project and demonstrate how you use technology to help you. Managing involves a lot more than planning. A live project can easily break down into chaos without good management. As a project manager, you will be responsible for managing a large amount of information about the progress of a project. You will be responsible for making a range of complex decisions to make sure a project is completed successfully. You are also responsible for communicating effectively about the progress of the project. Software packages such as MS Project1 can be very helpful. You should therefore be competent in using project management software.
At the end of the project you should submit a set of Gantt charts, graphs, tables and plans that illustrate and analyse knock-on-effects and new arrangements which should be accompanied by a brief narrative explanation of the progress and outcomes of the project and a critique of the software you employed. The deadline for the submission of this final report is week 13. All files should be submitted via Moodle and/or Turnitin. Please email your tutor if you have any questions.
Managing the Project
Having created, established and submitted the BPMS and the project plan, work starts delivering the project's products. Once the project is underway you will need to adjust, amend and re-plan the activities, the resources, the schedule and the risk register to keep everything on track and to cope with unexpected (or anticipated but unwelcome) developments. You must update your MS Project plan continually to reflect the current status, fine-tune the critical path, try to reduce increases in budget or time, monitor quality, evaluate possible implications and predict and control problems.
Needless to say, not everything will go according to plan (communication problems, delays in agreements, suppliers late, people off sick, equipment breaking down, costs going up, and the like). Remember, there is an argument that the very best project managers do not get the reward or recognition they deserve. Project managers are doing a good job if everything goes pretty much to plan and also when things go wrong but they successfully negotiate major challenges.
A large part of project management is how you manage the effects of project problems or exceptions. You should consider the impact and repercussions of what could go wrong with your plan, make arrangements to deal with them and put these into action when necessary. You should explore and decide how to bring the project back on track in terms of cost and timescale, agree this with your team and keep careful records of these changes. You should compare possible options (e.g.
1 Or equivalent software such as ProjectLibre
working weekends or overtime, employing extra resources) and decide which option is preferable and why. It is possible that there will be disagreements and that everyone in the group may not agree on a course of action, in which case a compromise may be sought. You should note these discussions, agreements and solutions. You will be able to reflect on them at the end. While you do this you should think about what you have learned about project management methodologies, which approaches and techniques do you find most useful and why?
Part B requires the production of:
1) A set of Gantt charts (demonstrating monitoring and controlling progress)
2) A presentation (summarising the objectives and outcomes of the project)
3) A final report (critically reviewing the project)
4) A technology report (evaluating the technology).
This second part of the coursework continues where the first part ended. You have already created and established the project Terms of Reference and baseline plan in your BPMS. You should spend the rest of the semester implementing the project. In other words now you put the plans into action and deliver the project product(s).
You have considered and established the aims and context of this project in the BPMS: you have explained who are the project owners, the stakeholders, their expectations and so on. You will also have considered the project management methodology. The next step is to follow the plans and track developments and changes in these project plans - the tasks, resources, costs, critical path, risks, etc.
1) The Project's Gantt Chart Plans
You have already entered the main tasks for the project and set the project baseline in Part A. This plan confirmed your expected schedule, set milestones and estimated the costs and completion date for the project. From the moment the actual work on the project starts, you must monitor, record and control your and your group's progress and the changes that are made to the baseline.
So in Part A you (each group) submitted the preliminary version of the Gantt chart (using software), containing your baseline plan, by week 8. This established your baseline schedule for the project board and confirmed important milestones, your planned budget and target date.
In Part B you (individually) update and review this original Gantt chart and (as you manage and work on the project and produce the project's deliverables) keep your own individual version up to date as the project progresses. Things seldom go exactly according to plan so changes will need to be made. Problems and issues arise that need to be allowed for. Therefore it is likely that you will create a number of updated versions of this Gantt chart (a copy of the final Gantt chart must be included in you final report). The Gantt charts provide useful material for reflection and lessons learned. These Gantt charts should be easy to read and printed on one or only a few pages. While you must identify the tasks you should try to minimize the space that the dependency table uses so that you can display the differences between planned and actual progress. Use A3 sized sheets if you like. These Gantt charts must be incorporated into the two reports you produce (the plan and the report) and not submitted as separate files.
So, you should each (individually) keep your own copy of the original Gantt chart for the project you are embarking on, before you start work delivering it. As a reminder: your baseline project Gantt chart should have about 20 to 30 tasks or activities. The project should require certain key resources that may be used throughout the project. There should be costs associated with different aspects of this project and with the use of these resources. If your baseline Gantt chart does not already have sufficient details about tasks, schedule, resources and costs please add them. You should have used software such as MSProject to do this. The first Gantt chart is your pre-start estimate, your initial plan.
Once work starts on the project, and at least once per week, you should update this Gantt chart with the latest amendments and developments and track how you are getting on compared to your expectations and your original baseline plan. Log and store these plans so that you can refer to them later and discuss/present them in the final report. It is important that you demonstrate that you know how to manipulate MSProject, or equivalent, to perform what-if analysis, appreciate the implications and consequences of changes and take account of project developments /updates.
Deliverable: The Gantt charts you include in your reports will show
• the baseline plan - an estimate of what will happen - including: tasks, durations, dependencies, critical path, resources, costs.
• The actual, delivered, project progress which shows the revised plan and the changes that were made - a Gantt chart of what actually happened including changes to, for example: tasks, durations, resourcing, costs.
2) Presentation
Imagine you are presenting a presentation to project board. When preparing the presentation, think about its purpose - what do the project board want to hear? (Remember, the project board may be monitoring the progress of a number of different projects.) The project board will be eager to hear about the project and what progress you have made. What were the objectives and what is the current status of the project? Is it on track in terms of time and cost?
When preparing the presentation, you should consider the clarity of the explanations given. This will probably include amended Gantt and other generated charts. You may mention the plans and deliverables and certain parameters. You should explain what has caused the project to deviate from the plan and what you did to correct it. You should also consider the clarity of the presentation; choose the outputs and reports from your software carefully to make it as clear as possible.
3) Final Report
Your project should be completed by week 13. Individually, you should summarize in a concise way, your view of the status and success of your project. Was it
completed successfully, did you achieve the objectives within time, budget and other constraints? Did you produce the products to the expected level of quality? Or would you consider it to have challenged outputs, outcomes and benefits? You should have had measures in place so that you can judge the outcomes of your project. This might include key performance indicators (KPIs) and feedback from some of the key stakeholders.
You should use this brief report as a chance to review and reflect on the outcome of your project. What are the lessons learned? What are your general reflections on the methodology and process? When reflecting on the methodology, you should consider the nature of this particular project - a relatively small project. How would things be different for a larger, more complex project? What about the overall group process; how effectively do you think your team worked together on the project?
4) Technology Report
You need to reflect on the usefulness (or otherwise) of the software you used. Do you think it helped or hindered you? How would you get on without any software? Entering, and updating all the project data accurately takes a lot of time and effort. Is it worth the effort? Does the software help you to manage the project effectively?
Are there any features which particularly impressed you? Any which you feel could be improved? If you had an opportunity to add new features, what would they be? There are hundreds of different packages and applications you could have used, would you be tempted to try different software next time?
Attachment:- Projects in Practice.rar