EF_Team2
Moderator
Posts: 2319
Joined: Mar 1, 06
Ref.#: 5713
|
Greetings!
While the specifics will, of course, depend upon what project environment you choose, you might want to consider some of the following: what notifications must be made to which departments? What documents must be prepared? Will a project completion report be generated, and if so, by whom? What are the final audit requirements? I'm sure you can come up with a longer list of things that needs to be covered. I find that starting an outline is often easier if I begin with a list and then hone it into an outline, letting the sub-topics fall into line under the major headings.
You might want to study some Project closeout reports and see how they are handled. If you use "Project closeout and audit" as your search term phrase, you will get several examples of outlines, which might help you to understand better what to shoot for.
I hope this helps get you started!
Thanks,
Sarah, EssayForum.com
|
mophe
Member
Posts: 24
Joined: Feb 4, 08
Ref.#: 5745
|
Based on your feedback, find attached below my project management term paper. Can you kindly help me review it?
Thanks!
Introduction
The importance and usefulness of project a project closeout and audit cannot be overemphasised irrespective of the size and nature of a project. I was involved in an electronic banking project a couple of years ago and in retrospect I now realise that the project was not properly concluded and never audited.
The project involved the implementation of a telephone banking system so that customers could manage their accounts remotely. This would mean that customer service officers were freed up from answering routine account enquiries and could focus on the marketing of the bank's services. A vendor was contracted to develop, deploy and implement the system. The project team comprised myself, my line manager (who also the head of the electronic banking department), the head of the IT department, three software developers from the IT department and staff from the vendor's company. The head of the project team was the head of the electronic banking department.
The project was not formally handed over by the vendor upon completion and the completion was just communicated verbally. With what I know now about project management, if I am involved in a similar project, I would ensure a proper project closeout and audit using the outline below.
1. Development of acceptance and delivery criteria
2. Plan the completion of the work
3. Formal handover by the vendor/verification of deliverables
4. Documentation of lessons learned
5. Conduct a project closure meeting
6. Documentation completion
7. Prepare a project closeout report for submission to the senior management team of the bank
8. Contractual aspects and financial accounting
9. Celebrate the completion and success of the project informally/ disbanding of project team
10. Carry out a post-implementation review
I will now proceed to discuss all the above-mentioned issues in detail.
1. Development of acceptance and delivery criteria
This will be mutually agreed upon with the vendor during the initiation/planning stage of the project (Rosenau, 1998). By doing this, both parties will be spared the surprises that can arise towards the end of the project. According to Bradley (1993), all the members of the project team will jointly agree on the acceptance and delivery criteria as well as how changes in the scope of the project will be managed. These will be captured in the project definition report (PDR) and products' description.
My bank's acceptance criteria will stipulate a formal training of the operations and technical staff that would manage the system prior to a formal handover of the project by the vendor. The training of staff will ensure that the bank is not dependent on the vendor for the daily administration of the system. If we had done this, we would not have been exploited by the vendor who charged us arbitrarily to resolve problems that should otherwise by the technical staff claiming they were not included in the maintenance /after sales support contract. Maximum system downtime levels expected during the testing phase would also be agreed upon (I would advocate 95%).
The PDR and products' description will be detailed enough to remove all elements of ambiguity and prevent problems that may occur at the closeout phase. Planning for project acceptance needs to start very early in the life of the project (Cooke-Davies, 2002)
2. Plan the completion of the work
A checklist will be prepared to show all the administrative and technical work that needs to be done to properly closeout a project (Frigenti and Comninos, 2002). For this project, Meredith and Mantel's (1995) checklist will be adapted and the following tasks that are to be done will be carefully planned.
1. Project office and project team organisation
o Conduct project closeout meeting
o Personnel performance evaluations
o Release staff
2. Financials
o Finalise financial documents and records
o Audit final charges and costs
o Prepare final project financials report
3. Project definition
o Document final 'as built' project scope
o Prepare final project work breakdown structure and file
4. Plans, budget and schedules
o Document actual delivery dates of all contractual deliverables
o Document actual completion dates of all contractual obligations
o Prepare final project and task status reports
5. Project evaluation and control
o Ensure completion of all work
o Prepare final evaluation reports
o Conduct final review meeting
6. Management and client reporting
o Submit the final report to the bank's management team
7. Contract administration
o Compile all final contract documents with revision, waivers and related documents
o Verify and document compliance with contractual terms
o Compile project acceptance documents
o Officially notify the bank's management team of project completion
8. Project records control
o Complete project files
o Dispose of other project records as required
9. Technical documentation
o Compile and store all technical documentation
o Prepare final technical report
10. Acceptance and handover
o Final delivery instructions
o Final client acceptance and handover
o Ownership transition plan
3. Formal handover by the vendor/verification of deliverables
The vendor will be required to prepare and submit a formal handover document to the project manager. The document will capture the following information.
o A detailed software specification as well as the source codes for the telephone banking application implemented (Cooke-Davies, 2002).
o A detailed specification of the hardware components used for the project. If this had been done, we would have realised that we could leverage on the unutilised capacity of the telephone banking server in the development of the internet banking application which was the next IT project undertaken by the bank rather than buying a new server (Cooke-Davies, 2002).
o A 'punch list' detailing any outstanding parts of the project, the personnel responsible for their delivery as well as scheduled completion dates (Piper, 2006).
o A confirmation of the training of the bank's staff and their ability to manage the system on their own (Cooke-Davies, 2002).
The project manager will forward this handover report to all the project stakeholders for their concurrence and system, user and operations acceptance letters will be written by them to confirm their acceptance of the project.
4. Documentation of lessons learnt
Throughout the implementation phase, members of the project team and other relevant stakeholders will review the progress of the project and highlight the areas that went better than predicted in the plan, the areas that went according to plan and the areas that did not go according to plan (Piper, 2006). The lessons learnt will be compiled by interviewing the members of the project team and getting their opinions about the performance, productivity, quality, development methods and overall management process of the project (Bradley, 1993). At the closeout phase of the project, all the lessons learnt will be compiled into a single document that will be reviewed during the project closeout meeting (Martin and Tate, 2002). Lessons learnt are best captured when they are still fresh in the minds of the project team and before the team is disbanded and members are assigned to other projects (Piper, 2006).
5. Conduct a project closure meeting
Buttrick (2005) suggests that the agenda outlined below can be used for a closure meeting
o Deliverables
o Outstanding issues
o Benefits and business plan
o Post-implementation review
o Acknowledgements
o Formal closure
o Lessons learnt.
The lessons learnt segment will be split into two categories
1. What did we do well?
2. In what areas could we have done better?
The lessons learnt review should not be used as an opportunity to apportion blame on the negative aspects of the project as this will lead to members of the project team covering up mistakes (Frigenti and Comninos, 2002). Rather, ideas/suggestions on how to apply the positive aspects of the project and to how to forestall the re-occurrence of the negative aspects on any outstanding parts of the project and other future projects the bank may wish to embark upon will be generated (Piper, 2006).
If we had held a project closure meeting, we would have been able to apply some of the knowledge garnered to the internet banking project because the project team was basically the same with that of the telephone banking project although it included a different vendor and two additional staff from the IT department. At the end of the project closure meeting, a business acceptance letter will be signed of by the bank's management representative.
6. Documentation completion
It is essential that all documents pertaining to the project are appropriately filed and kept up to date. This can prove very useful in the settlement of disputes if they arise at a later date. Additionally properly documented projects can provide reference materials for future similar projects the bank may wish to embark on and as a guide for other staff of the bank who maybe functioning as project managers on projects within their departments.
The project documentation will include some of the items specified by Frigenti and Comninos (2002) as listed below
o Originating documentation (business case, project proposal)
o Definition and planning schedules and documents (PDR, integrated project plan baseline)
o Performance and status documents (costs reports, performance evaluation reports, minutes of meeting
o General correspondence (memos, letters, electronic communication, faxes)
o Accounting and cost information
7. Project closeout report
After the project closure meeting, the project manager will prepare a report and present it to the bank's senior management team who are the sponsors of the project. The report will demonstrate the conformance of the project to the triple constraints of time, cost and quality. Cleland and Ireland (2002) point out that a project closeout report should address the following
o Final cost, schedule and technical performance accomplishments
o Final cost report
o Closeout approvals
o Closeout of contract
o Results of a project termination audit with a citation of the major lessons learnt
o Final supporting documentation
o Turnover and acceptance of official project files
o Development and finalisation of an official closeout agreement
A draft of this report will be circulated prior to the project closure meeting so that it can be amended based on the discussions and feedback received at the meeting (Buttrick, 2005)
8. Contractual aspects and financial accounting
We did not formally close the implementation part of the contract with the vendor and this subsequently led to the lines being blurred between what constituted project implementation and after sales maintenance and support. There were issues which arose after the system had gone live which the bank felt the vendor should take care of as part of the maintenance agreement but the vendor interpreted these as a change in the scope of the project that required additional funds.
Lock (2007) makes it clear it that accounts have to be properly closed out to prevent the incurring of additional expenses. In case of a future project, the implementation part of the contract will be signed off on upon the submission of a handover report by the vendor and the formal acceptance of the telephone banking system by the bank as contained in the various acceptance letters. This will ensure that there is a clear distinction between implementation and after sales support (Piper, 2006). It is important that contracts are closed to prevent unnecessary work being charged to the project after it has formally ended (Cooke-Davies, 2002).
9. Informal celebration of project completion and success/disbanding of project team
A project team should celebrate its success and recognise achievement to increase the motivation of its members (Project Agency, 2007). The project manager will organise an informal gathering of all the members of the project team and the vendor to congratulate themselves on a job well done. This will serve as a morale booster for the project team who will feel that their contributions are appreciated by the bank (Cooke-Davies, 2002).
As suggested by Piper (2006), some senior management staff of the bank will be invited to the gathering to demonstrate management's appreciation to the project team and its acceptance of the outcome of the project. Thereafter, members of the project team who are staff of the bank will be released from the project and can return to their departments to take on other tasks within the bank.
10. Post-implementation review (PIR)
One of the things that will be agreed upon at the project closure meeting will be setting a date for the post-implementation review of the project to ensure that it is conforming to the business case that led to its implementation in the first instance (Cooke-Davies, 2002). Buttrick (2005) states that the project closure meeting should agree on
o Who is accountable for organising and chairing the PIR
o The date it will occur
o Which functional stakeholders are required to participate?
I will recommend that this review be carried out three months after the handover of the telephone banking system by the vendor. According to Bradley (1993), during this review, the following important information should be elicited.
o Manpower requirements for running the system
o Response times of the system
o Error rates since implementation
o Operations from previous systems that have now been superseded
o Outstanding problems
o Performance of the system against its forecasted benefits
o Unplanned benefits of the system (if any)
o Reaction of the bank's staff to the new system (especially the customer service officers)
o Reaction of the bank's customers to the new system
Project Agency (2007) suggests that a project team can agree well in advance a date to hold a post project review meeting and include this in the Gantt chart.
Conclusion
Project closeout management can be a springboard for a whole set of future value-creating projects within an organisation (Cooke-Davies, 2002). Figure 1 shows the complexity involved in project closeout management.
Figure 1: The hidden complexity of project closeout management (Cooke-Davies, 2002)
In my bank the proper closeout of the telephone banking project would have served as a precursor for the planning and implementation of the internet banking project. Project closeout management if properly done gives people an opportunity to learn lessons while they are fresh in the memory and while the context is well understood. Lack of proper closeout management means an organisation cannot learn from its past to improve its future and will therefore keep doing things in the same way and yet expect better outcomes.
|