TMMPM In-Course Project

Project Management For Total Materials Management and Planning Project Elham Sarikhani John Wilson Mahshid Sajedi
Oskouei Intake Code: UC3F1205CSE Course Code: CE00348-3-PM Lecturer Name: Ms. Tham Hoong Ching Hand-in-Date: 10 July 2012 Hand-out-Date: 18 September 2012
Staffordshire University/ Level 3
Acknowledge
We would like to express my gratitude to my lecturer, Ms. Tham Hoong Ching whose method of demonstrating and teaching the modules as well as explaining with stimulating examples motivate us to get better understanding of the subject. Moreover, we would like to thank her for putting much more effort in illustrating the module tutorial by providing real environment examples and answering our problems during the module.
CE00348-3-PM
Asia Pacific Institute of Information Technology
Table of Contents
ACKNOWLEDGE ............................................................................................................................................... 1 1. INTRODUCTION............................................................................................................................................ 4 1.1 ASSUMPTION ................................................................................................................................................... 5 1.2 CURRENT DEVELOPED SYSTEM FAILURE FACTORS .................................................................................................... 5 1.3 PROJECT RECOVERY ........................................................................................................................................... 5 2. PROJECT MANAGEMENT METHODOLOGY ................................................................................................... 6 3. WORKLOAD MATRIX .................................................................................................................................... 9 4. GANTT CHART .............................................................................................................................................. 9 5. GROUPING REPORTED ISSUES .................................................................................................................... 10 6. PROJECT SCOPE MANAGEMENT ................................................................................................................. 11 6.1 ASSUMPTIONS ................................................................................................................................................ 11 6.2 PROBLEM DESCRIPTION .................................................................................................................................... 11 6.3 REMEDY SOLUTION ......................................................................................................................................... 12 7. PROJECT RISK MANAGEMENT .................................................................................................................... 15 7.1 ASSUMPTIONS ................................................................................................................................................ 15 7.2 PROBLEM DESCRIPTION .................................................................................................................................... 15 7.3 REMEDY SOLUTION ......................................................................................................................................... 15 8. PROJECT COST MANAGEMENT ................................................................................................................... 21 8.1 ASSUMPTIONS ................................................................................................................................................ 21 8.2 PROBLEM DESCRIPTION .................................................................................................................................... 21 8.3 REMEDY SOLUTION ......................................................................................................................................... 21 9. PROJECT HUMAN RESOURCE & COMMUNICATIONS MANAGEMENT ......................................................... 26 9.1 ASSUMPTIONS ................................................................................................................................................ 26 9.2 PROBLEM DESCRIPTION .................................................................................................................................... 26 9.3 REMEDY SOLUTION ......................................................................................................................................... 27 10. PROJECT QUALITY MANAGEMENT ........................................................................................................... 33 10.1 ASSUMPTIONS .............................................................................................................................................. 33 10.2 PROBLEM DESCRIPTION .................................................................................................................................. 33 10.3 REMEDY SOLUTION ....................................................................................................................................... 33 11. PROJECT PROCUREMENT MANAGEMENT ................................................................................................ 38 11.1 ASSUMPTIONS .............................................................................................................................................. 38 11.2 PROBLEM DESCRIPTION .................................................................................................................................. 38 11.3 REMEDY SOLUTION ....................................................................................................................................... 40 12. INDIVIDUAL REFLECTIONS ........................................................................................................................ 46 12.1 ELHAM........................................................................................................................................................ 46 12.2 JOHN .......................................................................................................................................................... 48 12.3 MAHSHID .................................................................................................................................................... 50 13. CONCLUSION............................................................................................................................................ 52 14. APPENDICES ............................................................................................................................................. 53 14.1 APPENDIX A: PROJECT CHARTER ...................................................................................................................... 53
CE00348-3-PM

14.2 APPENDIX B: WORK BREAKDOWN STRUCTURE ................................................................................................... 60 14.3 GANTT CHART ............................................................................................................................................ 64 15. REFERENCE ............................................................................................................................................... 69
List of Tables
TABLE 1 PMBOK VS. PRINCE2 SOURCE: PETER WHITELAW, 2005 ..................................................................................... 6 TABLE 2 PMBOK VS. PRINCE2 SOURCE: (WIDEMAN, 2002)............................................................................................. 7 TABLE 3 GROUPING REPORTED ISSUES ........................................................................................................................... 10 TABLE 4 PROJECT SCOPE MANAGEMENT PROCESSES ........................................................................................................ 12 TABLE 5 SCOPE DEFINITION TOOLS AND TECHNIQUES ....................................................................................................... 13 TABLE 6 PROJECT SCOPE STATEMENT COMPONENTS ........................................................................................................ 14 TABLE 7 RISK MANAGEMENT COMPONENTS, SOURCE: SCHWALBE, 2010 ............................................................................ 16 TABLE 8 RISK MANAGEMENT PLANNING COMPONENTS DESCRIPTION ................................................................................. 16 TABLE 9 SAMPLE RISK REGISTER ................................................................................................................................... 18 TABLE 10 RISK RESPONSE FORM ................................................................................................................................... 20 TABLE 11 EARNED VALUE ANALYSIS .............................................................................................................................. 24 TABLE 12 PROJECT TEAM DIRECTORY ............................................................................................................................ 28 TABLE 13 COMMUNICATIONS MATRIX .......................................................................................................................... 29 TABLE 14 TMMPM SOFTWARE QUALITY MEASURE........................................................................................................ 35 TABLE 15 QUALITY ASSURANCE ACTIVITY ....................................................................................................................... 36 TABLE 16 DEFECT LOG SAMPLE .................................................................................................................................... 36 TABLE 17 QUALITY CONTROL SAMPLE CASE..................................................................................................................... 37 TABLE 18 PMBOK GUIDELINES ON PROCUREMENT PLAN ................................................................................................. 41 TABLE 19 HYPOTHETICAL SPECIFICATION FOR PCS AND SERVERS ........................................................................................ 41 TABLE 20 CONDUCT PROCUREMENTS ............................................................................................................................ 42 TABLE 21 PROJECT GOALS, BUSINESS OUTCOMES, AND OBJECTIVES ..................................................................................... 54 TABLE 22 TMMPM MILESTONES ................................................................................................................................ 55 TABLE 23 ROLES AND RESPONSIBILITIES ......................................................................................................................... 58
List of Figures
FIGURE 1 WORKLOAD MATRIX....................................................................................................................................... 9 FIGURE 2 RISK BREAKDOWN STRUCTURE........................................................................................................................ 17 FIGURE 3 PROBABILITY/IMPACT MATRIX ........................................................................................................................ 19 FIGURE 4 COST MANAGEMENT OVERVIEW (SOURCE: PMBOK GUIDE PG. 39) ..................................................................... 22 FIGURE 5 TMMPM EARNED VALUE ANALYSIS ............................................................................................................... 25 FIGURE 6 SOLUTION FRAMEWORK FOR ISSUE NO.15 (SOURCE: CAGLE, 2003, P.140) ........................................................... 44 FIGURE 7 INPUT, TOOLS AND TECHNIQUES REQUIRED FOR SOLVING PROBLEM NO.15.............................................................. 45 FIGURE 8 ORGANISATION STRUCTURE FOR TMMPM PROJECT ......................................................................................... 57 FIGURE 9 WBS, PHASES AND WORK PACKAGES ............................................................................................................... 61
CE00348-3-PM
1. Introduction
Project Management can be defined as planning and systematization of an organization's resources in order to lead a specific task, duty or event toward completion. This project is concentrated on case study regarding a multinational company which is about to implement and deploy a new automated system to assist the manner in which materials and services are contracted and procured within the various departments in its office. The outcome system is going to replace the current manual system. In order to reduce the cost and risk of manual system, enhance the quality of existing processes and to assist the manners of conducting procurement within various departments in the office, a new system is to develop that particularly automates the process of contract selection, approval and award processes. As a result of employing this new system all of the procedures and processes will take place online, all the employees of all departments will be able to access the system which going to be provided with standard, support and guideline for material management. The focus of project is on quick delivery and efficient consumption of resources while guaranteeing integrity and stability of new system. As the project involved all the departments in the regional office and required a central repository in order to store and access information to approve the various department services and contracts, it focused on quick delivery with some major milestones to ensure the deadlines were met. In total there were 9 departments and the system required 360 new PCs and 6 new servers. The project was supposed to be completed in time duration of 12 months. Even though as the project progressed, it has been meeting its high-level milestones for the first 9 months, with 3 months left, it was considered as failing to meet its target dates, not doing what it was supposed to do and was unreliable. Consequently, our group consisting of three members has called in in order to find solutions to the 15 problems that were faced in this project development.
CE00348-3-PM
1.1 Assumption
The outsourcing company is able to handle the project it has its own guidelines used in procurement contract. Project Sponsor will provide additional funds for companys budget because the funds that left in the company is getting lower. Every department will be supporting the project team by supplying resources. All the rules and regulations are accepted by all the employees. All works and resources are only for 3 months period.
1.2 Current Developed System Failure Factors

After 9 months the project progression meets its high-level milestones. The following failure factors are deemed: Failure to meets its target dates. Not doing what it was supposed to do. It is unreliable.
1.3 Project Recovery

It is evident that a project recovery effort is needed with solutions identified and invoked to get the TMMPM project back on schedule and rolled out as planned.
CE00348-3-PM
2. Project Management Methodology

In the list of problems in this project has been stated that there is no evidence that a proper project management process was followed (issue no. 14). Having no project framework in place or adopting an improper methodology caused problems such as: Cost and Schedule slippages Miscommunication within the team Wasting time on performing administrative tasks that have no clear purpose Dependency on technical wizardry to complete the projects Project management exhaustion
To resolve these problems the team investigated the two of most famous available approaches to managing project activities: 1) Project Management Body of Knowledge (PMBOK) 2) Projects in Controlled Environments Ver.2 (PRINCE2) PMBOK is a project management guide and an internationally recognized standard. PRINCE2 in the other hand is a widely recognized de facto standard used extensively by the UK government and in the private sector. Table 1 and 2 are brief comparisons on the two referred methodologies.
Table 1 PMBOK vs. PRINCE2 source: Peter Whitelaw, 2005
Components Integration Management
PMBOK v4
PRINCE2
Has change control in managing any Has change control in managing changes changes during the development of during the development of the project. It the project. It also integrating few helps in changing the requirements, the types of elements in project specification and conditions which are not satisfied.
managements. Scope, and Cost
Time Scope, Time and Cost Management Prince2 has Plans and Business Case are included in PMBOK which help which help in plannning the business, cost in managing the scope, cost and the estimation and scheduling of the project. scheduling of the project.
Quality Management
Project
Quality
Management
is Covered
in
Quality/Quality
Review,
covered to have quality control in Configuration Management in Prince2. production.
CE00348-3-PM
Staffordshire University/ Level 3 Components Human Resource Management Processes PMBOK v4 in organizing PRINCE2 and Only role and responsibility in managing team members are covered in
managing the team to work out the the project are documented in detailed.
organization.
Risk Management
Project Risk Management is covered Management of Risk is covered in Prince2, in managing the risks that might be which will have risk identification, risk facing during the progression of the analysis, risk planning and risk monitoring project. and control.
Procurement Management
Project Procurement Management is Not covered by Prince2 covered which will be outsourcing the projects to other organizations.
Table 2 PMBOK vs. PRINCE2 source: (Wideman, 2002)
PMBOK Comprehensive Largely descriptive prescriptive on a high level Core and facilitating processes; need to be scaled to needs of project Customer requirements driven Sponsor and stakeholders Human Resources Procurement recognizes that the project needs assessment or feasibility study may be the first phase of the project
PRINCE 2 Focuses on key risk areas only; does not claim to be complete Highly prescriptive, especially on Process Structure , but adaptable to any size project All processes should be considered; also need to be scaled Business case driven Clear Project Ownership and direction by senior management Limited organization planning Does not cover procurement , leadership , people management skills Akin to construction management (PRINCE2 vs. Guide) -missing solution gathering and feasibility studies
PMBOK Advantages: PMBOK covers the actual procurement, pre-assignment or negotiation for team members for a project in detail whereas PRINCE2 does not cover this. PMBOK provides greater detail on tools and techniques (G J Rankins, 2009) PMBOK identifies necessities to be covered in human resource management.
CE00348-3-PM
Justification of Chosen Methodology PMBOK seems to fit best since it is a comprehensive method that covers a wide range of activities in a project. PRINCE2 is focused on risk areas mostly besides, there are issues in TMMPM project regarding procurement management which is not covered in PRINCE2. Further investigation on PMBOK proved to us the 15 reported startling issues could be well fitted to 9 knowledge areas in this method and if well utilized, this project can be successfully carried out within the remaining time provided.
CE00348-3-PM
3. Workload Matrix
Elham Introduction Selection of Methodology Grouping reported issues Scope Management Procurement Management Risk Management H/R & Communication Management Quality Management Cost Management Conclusion Execution Summary Project Charter WBS Referencing
Figure 1 Workload Matrix
John
Mahshid
4. Gantt Chart
Gantt chart is provided in Appendix C.
CE00348-3-PM
5. Grouping Reported Issues

After selecting the methodology, next step is grouping the reported problems. The outcome is represented in Table 3:
Table 3 Grouping Reported Issues
Problems associated with Project Scope Management 1 2 3 There was a weak business case (justification) The project approval was not formally documented There were no clear designated sponsors for the project
Problems associated with Project Cost Management 11 The project was already running out of funds
Problems associated with Project Human Resource & Communications Management 4 6 13 5 There was no clear organizational structure to manage the project The project managers authority was constantly overridden by the department head /managers Technical skills were especially lacking in the network and security areas Most department heads felt that their department was the most important user of the system and focused on their needs only
Problems associated with Project Quality Management 10 The testing plan was not developed yet
Problems associated with Project Risk Management 9 The risks associated with the project, although documented, had no detailed action plans and were not categorized in terms of impact or severity
Problems associated with Project Procurement Management 7 The PC and server hardware technical specifications were constantly being changed to suit new or added requirements The hardware and software delivery was still being negotiated while there were only 3 months to complete the project The current network infrastructure needed a major upgrade to support the PCs and servers for the new system It was generally felt that the in-house developed system was not very different from a vendor developed software, e.g. SAP
12
15
Selection and Justification of Methodology 14 There is no evidence that a proper project management process was followed
CE00348-3-PM
10
6. Project Scope Management

6.1 Assumptions
Provided Project Charter is so ambiguous and lack the required details. No WBS has been provided.
6.2 Problem Description

6.2.1 Issue No. 1 There was a weak business case.
A weak Project Scope Statement has been developed during the scope definition process which causes the weak definition of project objectives, requirements, boundaries, deliverables and other critical components of the project scope statement. This is due to the fact that during the project initiation phase in project integration management the business case has not been defined properly. Instead of re-initiating the whole project the project management team will be redone the scope definition process to overcome this issue. While this is completely true, re-initiating the project is not a practical solution to overcome this issue. Re-initiation project starts everything from scratch which throwing away everything which has been done to until now. Nickson, 2005, claimed that, it is expensive, wasteful, and it requires a flexible timetable. It has been seen to work only where the project was not yet on the critical path for overall delivery. 6.2.2 Issue No. 2 The project approval was not formally documented.
Project approval requirement is a document which identifies approval requirements that can be applied to matters such as project objectives, documents and deliverables. The input to this process is the project charter which is formally authorizing the project. Updates to the Project Charter and scope definition will be solved this issue.
CE00348-3-PM
11
6.2.3 Issue No. 3 There were no clear designated sponsors for the project
Project charter which is developed during the project initiation identifies the key stakeholders of the project and is critical input to the scope management process. Updated project charter will be clearly identified key stakeholders along with the project sponsor.
6.3 Remedy Solution

The team came to understanding that aforesaid problems can be solved throughout employment of proper scope management strategy. Defining and managing the project scope influences the projects overall success. Schwalbe (2010) claimed that one of the most important and most difficult aspects of project management is defining the scope of the project.
Table 4 Project Scope Management Processes
Process
Description
Output Project scope management plan,
Involves documenting the features Scope Plan and functions of the product and processes involved
which consists of stakeholder requirements, requirements management plan and traceability matrix
Involves reviewing the project Scope Definition charter, requirements documents, and organizational process assets to create a scope statement Involves subdividing the major Create WBS project deliverables into smaller, more manageable components Involves formalizing acceptance of Scope Verification the project deliverables by key stakeholders Involves controlling changes to Scope Control project scope during the life of the project
Project scope statement and updated project scope management, and requested changes
Work Breakdown Structure, WBS dictionary, scope baseline
Accepted deliverables, requested changes Requested changes, Recommended corrective actions, and updated project scope statement, WBS, scope baseline, organizational process assets
CE00348-3-PM
12
As depicted in Table 4 Project Scope Management includes the processes involved in defining and controlling what work is or is not included in a project. It makes sure that the project team and stakeholders have the same understanding of what products the project will produced and what processes the project will use to produce them (Schwalbe, 2010). Scope management processes must be redone in order to identify scope of the project and to complete essential documents such as project scope statement which form the foundation of the project and defines what will be expected from the project. Updated Project Charter (Appendix A) also redefines project foundations and authorization which will be able to solve several issues fall under scope management. Plan By analyzing information contained in the project charter, and preliminary scope statement, along with project management plan, organization process assets, and relevant enterprise environmental factors the project management team will produce the project scope management plan (PMI, 2004) which further be the input to identify and verify the scope of the project. Scope definition It is to define in detail the scope or work required for the project. It will help improving the accuracy of the project objectives and it defines the baseline for performance measurements and project control (Schwalbe, 2010). Several tools and techniques (Table 5) are used to identify the projects scope (PMI, 2004).
Table 5 Scope Definition Tools and Techniques
Techniques Product Analysis

Alternative Identification Expert Judgments Stakeholder Analysis
Description It is to translating project objectives into tangible deliverables and requirements It is a technique used to generate different approaches to execute and perform the work of the project Each application area has experts who can be used to develop portions of the detailed project scope statement It identifies the influence and interests of the various stakeholders and documents their needs, wants, and expectations.
CE00348-3-PM
13
The output of scope definition is the project scope statement which comprises of the following components (PMI, 2004):
Table 6 Project Scope Statement Components
Component Project objectives

Product scope description Project requirements Project boundaries Project deliverables Project acceptance criteria Project constraints Project assumptions
Description include the measurable success criteria of the project describes the characteristics of the product that the project was undertaken to create describes the conditions or capabilities that must be met, stakeholder analyses are translated into prioritized requirements identifies what is included of excluded in or from the project include both the outputs that comprise the, as well as ancillary results defines the criteria for accepting completed products lists and describes the specific project constraints associated with the project scope lists and describes the specific project assumptions associated with the project scope and the potential impact of those assumptions if they prove to be false the organization of the project, the members of the project team, as well as stakeholders, are identified and documented identifies the known risks the customer or performing organization can identify milestones and can place imposed dates on those schedule milestones describes any limitation placed upon funding for the project, whether in total value or over specified time frames the projects cost estimate factors into the projects expected overall cost describes the level of configuration management and change control to be implemented on the project identifies those specification documents with which the project should comply identifies approval requirements that can be applied to items such as project objectives, deliverables, documents, and work
Initial project organization Initial defined risks Schedule milestones Fund limitation Cost estimate Project configuration management requirements Project specifications Approval requirements
Work Breakdown Structure (WBS) The WBS is a deliverable-oriented hierarchical decomposition of the work which should be executed by the project team, in order to achieve the project objectives and create the required deliverables (PMI, 2004). The proper WBS also helps the development of the Scope Baseline which consists of the approved detailed project scope statement and its associated WBS and WBS dictionary. (Appendix B)
CE00348-3-PM
14
7. Project Risk Management

7.1 Assumptions
The problems at TMMPM indicated a major failure of its previously provided risk plan.

7.2.1. Issue No. 9 The risks associated with the project, although documented, had no detailed action plans and were not categorized in terms of impact or severity It is the responsibility of the project risk management team to plan, identify, analyze, response, and control positive or negative risks that are opportunity or threat to the project success respectively. It is claimed that several risk management process has been done but it has not categorized and qualified properly for deciding the best avoidance or enhancement response on the occurrence of them. A poor risk management plan might be caused this problem to be arisen which leads to inaccurate identification and qualification of risks. There are several important documents which must be completed and updated during the each risk management process phases. A poor risk management plan may also lead to inappropriate completion of these documents which are crucial to the project risk management.
7.3 Remedy Solution

The first action that needs to be taken is to prepare a risk management plan. Conducting eligible risk management can have positive impact on significant improvements in the ultimate success of project. Risk Management can be executed throughout selecting projects, determining the scope of projects, and developing realistic schedule and cost estimations. It can help project stakeholders to understand the nature of the project meanwhile it involves team members in defining strength and weaknesses, and helps to maintain the integration in between the other project management knowledge areas (Schwalbe, 2010). According to PMI, PMBOK Guide project risk management consists of the following components in Table 7.
CE00348-3-PM
15

Table 7 Risk Management Components, Source: Schwalbe, 2010
Process Risk Management Planning Risk Identification Qualitative Risk Analysis Quantitative Risk Analysis Risk Response Planning
Risk Monitoring and Control
Outputs Risk management plan Risk register Risk register updates Risk register updates Risk register updates, risk-register contract decision, change request, project management plan updates, project document updates Risk register updates, organizational process assets updates, change requests, project management plan updates, project document updates
Planning Risk planning must be performed early during the project planning since it is crucial to successfully performing the other processes (PMI, 2004). Project manager and selected project management team members along with several stakeholders must be met at this stage. According to PMI PMBOK Guide, 2004, several components must be discussed and decided during this meeting which is listed, along with each description, in the Table 8. Input to this stage is the Project Scope Statement which has been discussed earlier, and the output is Risk Management Plan.
Table 8 Risk Management Planning Components Description
Topic Methodology
Description Defines approaches, tools and data sources used to perform risk management on the project Defines the risk management team and corresponding Roles and responsibilities activities (Appendix A) Cost estimation to perform risk-related activities Budgeting Schedule estimation to perform risk-related activities Timing The main categories of risks that should be addressed, Risk Risk categories Breakdown Structure (Figure 2) Definitions of risk probability and The probability and impact level of risk items along with scoring a interpretation method to be used impact Used to prioritized risks Probability and impact matrix Stakeholders tolerance update according to risk Revised stakeholders' tolerances management planning Risk management format and reporting process Reporting formats Tracking Track and documentation of the risk management activities, The say risk management processes will be audited
A Risk Breakdown Structure (RBS) has been developed during the risk planning stage which identifies the risk categories. RBS is a hierarchical representation of potential risk categories
CE00348-3-PM Asia Pacific Institute of Information Technology 16
for a project and is a useful tool to help project manager consider potential risks in different categories (Schwalbe, 2010).
TMMPM Project
Business
Technical
Organizational
Project Management
Competitors Competitors
Hardware
Executive Support
Estimates
Suppliers
Software
User Support
Communication
Competitors Cash Flow
Network
Team Support
Resources
Figure 3 Risk Breakdown Structure
Identification Several risk identification tools and techniques must be used in risk identification process to understand what events might affect the success of the project positively or negatively. According to (PMI, 2004) risk identification comprises of the following tools and techniques: Document Reviews Information Gathering Techniques Checklist Analysis Assumption Analysis Diagrammatic Techniques
The main output of the risk identification process is the Risk Register. Table 9 shows the sample risk register which has been developed during this stage of the project risk management. This table will be updated during the qualification and response stages of the risk response plan.
CE00348-3-PM
17

Table 9 Sample Risk Register
No. R1 R2 R3 R4 R5
Risk Equipment are more expensive than what is expected Under estimation of schedule Fail to acclimatize to new hardware configuration Fail to acclimatize to new software configuration Continues changes of scope
Category Cash Flow Estimates Hardware Software Executive support
Potential Responses Earn Value Analysis, Expert Judgment, Analyzing past project Gantt chart, Analyzing past project Expert Judgment, Analyzing past project Expert Judgment, Analyzing past project signed off system requirements specification signed off system requirements specification, continue communication with the client, use of best software engineering practices use of best software engineering practices Expert Judgment use of best software engineering practices Signed off the project charter
Response Strategy Avoidance Avoidance Avoidance Avoidance Mitigation
Risk Owner PM PM PM SDM PM
R6
Efficiency of the system is lower than client expectation
Software
Mitigation
PM
R7 R8 R9 R10
Components contain Bugs Network Failure Failure to shift from manual system to new system No sponsor to fund
Software Network User Support Suppliers
Mitigation Mitigation Avoidance Avoidance
SDM Mark PM PM
Analysis Qualitative risk analysis involves assessing the likelihood and impact of identified risks, to determine their magnitude and priority (Schwalbe, 2010). Figure 3 demonstrates Probability/Impact Matrix of identified risks derived from both problems which might threaten the project. Risk probabilities are described as being high, medium, or low. This will show the probability of occurrence of each problem along with their impacts on project.
CE00348-3-PM
18
High R4 R3
R7 R10
Probability
Medium
Low Low Impact

Figure 4 Probability/Impact Matrix
R6 R8 R9 Medium
R5 R1 R2 High
Response Plan Appropriate response must be assigned to identified and qualified risks which have been found during qualification process. Different strategies must be developed for reducing negative risks and enhancing positive risks. There are four basic responses for negative risks (Schwalbe, 2010): 1. Mitigation, which is reducing the probability and/or the impact of an adverse risk. This is primarily used for those risks that are to be managed by the project team. 2. Acceptance, which is accepting the risk as is and doing nothing. This is generally taken for those risks with low Risk Factors. It may be used for higher rank risks where a contingency plan is developed. If the risk occurs the contingency plan is put into operation. 3. Avoidance, which is eliminating the cause of the risk such as revising the scope to exclude that part involving the risk. 4. Transference, which is placing the responsible for the risk and it consequence on someone outside the project. A Risk response plan has been developed to assist in this process. Table 9 will get updated as project proceeds also a detailed form for keeping records on each response will be filled just as its been put in Table 10.
CE00348-3-PM
19

Table 10 Risk response form
Risk Description Risk Item Identifier Risk Priority Risk Factor Risk Response Strategy Risk Status Last Updated Risk Owner Date Assigned Consequence if Risk Occurs Areas where Probability may be Reduced Areas where Impact may be Reduced Attachments Action Items
Enter the description of the risk as stated in the Risk Management Plan R1 8 Mitigation Open 2 Aug 2012 Tony 31 July 2012 Impact on scope and costs. Shorten the time in between the cost estimation and the purchasing equipment. Consider at least 15% difference while estimating the cost. ---The team will conduct accurate cost estimation.
CE00348-3-PM
20
8. Project Cost Management

8.1 Assumptions
The cost for upgrading the network hasnt been estimated. The team including 6 members and 1 manager has been working on TMMPM in past 9 months.

8.2.1 Issue No. 11 According to the given report, after nine months of project progression, the project is running out of funds while consider amount of cost and expenses are still pending. Whereas the system required 360 new PCs and 6 new servers also the networks infrastructure and software need to be updated in order to support the new system, the cost of these two main categories of requirements is still in negotiation phase. This failure could be due to the fact that the project funds were not adequately calculated and proper cost controlling techniques and procedures were not enforced throughout the project. In order to meet the deadline and complete the project in the next three months, we need to allocate resources for the new systems and additional hardware which is needed to upgrade for network infrastructure also were required to apply an appropriate cost controlling procedures which needs to be fulfilled by the resources needed and new organization structure which is accessible in Appendix A.
8.3 Remedy Solution

Following tasks required to be done in order to complete the project on time: By making use of the Work Breakdown Structure (WBS) which has been produced in Scope Management Section (Appendix B) cost and recourses can be adjusted. The settled estimation have to cover the cost of outsourcing the development effort as per the new project team is put together. The team has to also include previously unaddressed costs such as upgrading the network. The financial plan is formulated based on the cost estimation. After obtaining the cost plan, next step would be applying cost controlling procedures using tools and techniques showed in figure 4.
CE00348-3-PM
21
Figure 5 Cost Management Overview (Source: PMBOK Guide pg. 39)
Expert Judgment is used during the generation of cost estimates. Expert Judgment is widely used and acknowledged as effective technique for generating estimates. (Rush, C., Roy, R., 2001) Using Expert Judgment to come up with cost estimations has benefits some of which are outlined below: Quick to produce; This is important especially for this project since TMMPM project should be finish in only three months. Requires little resource in terms of cost and time; Again we should consider the limited resource available for the job. Can be as accurate as other more expensive methods (Hughes, R. T., 1996) The accuracy is result of employing the insights attained from previous similar projects. The budget has been prepared to address the current problems which include upgrading the network infrastructure which has not been identified at the initial stages of the project. It also takes into consideration the additional man-hours required to finish the project during the next 3 months.
CE00348-3-PM
22
Staffordshire University/ Level 3 Details PCs Software Server Backup Devices Switches & network Design Cable Miscellaneous Total Quantity Unit price (USD) 360 1 6 2 15 1 1 1,700,00 2,000,00 8,000,00 8,060,00 1200.00 9,300,00 7,000,00 Total (RM) 612,000,00 2,000,00 48000,00 16,120,00 18,000,00 9,300,00 12,000,00 717,420,00
The project team was part of the system for the first 9 months.
Details Project Manager Team Member Total Quantity 1 6 Per Month/person 4,5000,00 2,500,00 Per9 Month/person 40,500,00 22,500,00 Total(RM) 40,500,00 135,000,00 175.500,00
The next three months will be done by external project team. 900 Man-days is based on 10 people working for the next 3 months.
Details Man-days(10303) (Strategic recovery)plan External Consulting Total Quantity Per Day/person 900 1 150.00 3,000,00 Total (RM) 135,000,00 3,000,00 138,000,00
Hence the total budget is RM 1,030,920.00
Cost Monitoring and Control The tool employed in monitoring the cost is Earned Value Analysis. As decided on project charter this project has 6 milestones (Table 22, Appendix A) in which the progress checking will be performed. Table 11 is Earned Value Analysis summary of the TMMPM project. Earned Value Analysis is considered as a good tool because it integrates cost, scope and schedule moreover it can be used to forecast project completion dates as well as future
performance. It can also provide an early warning project management tool that enables managers to identify and control problems before becoming insurmountable. Hence it allows projects to be managed on time and on budget. (Suketu Nagrecha, 2002) Where Earned Value calculated at each milestone is less than the Actual Value, the team would realize that the work has been over-budgeting as well as behind the schedule. Negative cost variance indicates over-budgeting, negative Schedule variance means the project is behind the schedule, cost performance value is indicating to the amount of money which has been eared out of spending every 1RM.
Table 11 Earned Value Analysis
Milestone Budget at Completion Planned Value Actual Cost Earned Value Cost Variance Schedule Variance Cost Performance Index Schedule Performance Index
8/6/2012 1,030,920 249,216 230,100 240,100 10,000 9,116 1.04 0.96
8/17/2012 1,030,920 396,480 381,100 387,364 -6,264 9,116 1.02 0.98
9/3/2012 1,030,920 566,400 551,020 558,284 -7,264 8,116 1.01 0.99
9/14/2012 1,030,920 691,008 673,420 683,292 16,588 1,000 1.02 1.00
10/4/2012 1,030,920 894,912 877,324 887,196 17,588 0 1.02 1.00
10/17/2012 1,030,920 1,030,848 1,013,224 1,023,132 17,624 0 1.02 1.00
Figure 5 is the graphical representation of Earned Value Analysis for TMMPM project.
CE00348-3-PM
24
Figure 6 TMMPM Earned Value Analysis
CE00348-3-PM
25
9. Project Human Resource & Communications Management

9.1 Assumptions
Top executives failed to establish a dynamic organizational structure thus leading to poor communication among employees and stakeholders. The Employees were mainly bred to focus on short term project goals rather than the overall success of the project. The Employees did not receive regular training in order to ensure that their technical skills were up to date with the market standard. The TMMPM working culture wasnt favorable to addressing employee requests in timely fashion thus further steered project failure. The TMMPM project overlooked monitoring, control and performance reporting as a whole.

Having been operational for 9 months and failing only into its last financial quarter of operation, its indeed possible that the TMMPM project overlooked communication and effective HR as vital inputs to successful project management. In the case of the TMMPM project, communication planning might have been done at the onset but during the execution phase, information reporting might have been overlooked thus hindering the need to carry out successive performance reporting. 9.2.1 Issue No. 4 There was no clear organizational structure to manage the project Because of the unknown organization structure the people who involved in this project are uncertain about their roles, responsibilities and to whom they should report and whose instruction they should follow. Base on the existing reports of the project such as job overlap frequently happening, some task are behind the schedule due to nobody take the responsibilities, etc., all illustrate the absence of the clear organization structure. 9.2.2 Issue No. 5 Most department heads felt that their department was the most important user of the system and focused on their needs only
When the department heads causes a conflict or separation between the departments by having an idea of being superior; this can cause a negative huge affection on the project
organization and the stakeholders. Since stakeholders are an integral part of a project. They are the end-users or clients, the people from whom requirements will be drawn, the people who will influence the design and, ultimately, the people who will reap the benefits of your completed project. The way in which this problem can be solved is just by identifying these stakeholders and work on project charter as provided input. These departments should have focused on the importance of building relationships as they communicate project information. As when numbers of the people that need to communicate increases, the communication channels also increases. 9.2.3 Issue No. 6 The project managers authority was constantly overridden by the department head /managers This problem is similar to issue no. 5, since they were things were in TMMPM project the department head/managers were giving not only the other departments a hard time but also the project managers authority was also overridden. 9.2.4 Issue No. 13 Technical skills were especially lacking in the network and security areas The lack of technical skill in security and networking are sensible. The people who involved in both hardware and networking have lack of experience and knowledge. Their inaccurate information often causes many miscalculations and misleading on decision making.
9.3 Remedy Solution

Creation of a Communication Management Plan and Increased Performance Reporting Going by the PMBOK structure, its been concluded that for the TMMPM project to recover from its current state, there is need to develop a communication management plan and also increase performance reporting. This measure will serve provide round the clock information updates to the respective stakeholders and project leaders in order for them to make better decisions. In the case of the TMMPM project, one of the problems evident is that there was no clear organizational structure to manage the project and that the project managers authority was constantly overridden by the department heads /managers; this in turn meant that information between the stakeholders of the project wasnt properly relayed and instances where decisions had to be made urgently were probably overlooked thus leading to project failure. Organization Structure for TMMPM project has been provided in project charter Appendix A.
Creation of a communication management plan will not only serve to ensure timely and appropriate generation, dissemination and storage of project information, it will also serve to specify the stakeholders responsible for each task. This process will start by determining the stakeholders who need the information, when they need it and eventually how the information will be delivered to them. Once a good communications management plan is established it will in turn address the issue of decisions being overridden as stated. The communication management plan will serve to ensure there is a dependable chain of information flow within the TMMPM project. It should be noted that for this process to be as effective as it states to be, the information should be availed to the respective stakeholders in timely fashion. (Table 12 and 13) A good communication management will at least feature the following elements. Stakeholder communication requirements. Information to be communicated, including format, content, and level of detail. Person responsible for communicating the information. Person or groups who will receive the information. Person or groups who are responsible for making decisions. Methods used to convey the information, such as hard copy and email. Frequency of the communication, such as weekly or monthly.
Beside what has already included in project organization section in project charter as roll and responsibilities in Appendix-A, the Following tables will show examples of both a project team directory and a communications matrix that will be essential towards the implementation of a convenient communication management plan in the case of the TMMPM Project. Project Team Directory
Table 12 Project Team Directory
Role Project Sponsor/ Client Project Manager System Developer Manager Software Team Lead (Team #1)
Name Bruce Wayne Elham Sarikhani
Email bruce_wayne@gotham.cc elham.herenow@apiit.com.my john@apiit.com.my freeman65@waynent.cc
Phone Contact (+1) -899 939320 (+60)- 232 44343 (+60)- 653 22364 (+60)- 674 90312
John Wilson
Mahshid Freeman
CE00348-3-PM
28
Staffordshire University/ Level 3 Role Software Team Lead (Team #2) System Testing Management Procurement Management Quality Assurance Installation (Hardware/Software) Name Sam Hathaway Sara Hardy
Tony Cotillard Tom Hanks Mark Fisherman
Email hathaway@apiit.com.my t_Hardy65@apiit.com.my Cotillard_m@apiit.com.my hanks@waynent.cc Mark_81@waynent.cc
Phone Contact (+60)- 322 65432 (+60)- 821 03923 (+60)- 712 73434 (+60)- 674 91112 (+60)- 322 61432
Communications Matrix
Table 13 Communications Matrix
Communication Type Project Kick Off Meeting Project Team Meetings Technical Design Meetings
Objective of Communication Introducing the Project Review Project Milestones Discuss technicalities during implementation Inform the Management of current project status Generate status reports Highlight the objectives and minutes of previous meetings
Medium Face to Face Face to Face Face to Face
Frequency Once Weekly Every 2 Weeks
Audience Project Manager, Staff Project Team 1 &2 Project Team 1 &2
Owner Project Manager Team Lead
Deliverable Meeting Minutes Meeting Minutes Meeting Minutes
Team Lead
Project Status Meetings Project Status Reports Technical Design Meeting Reports
Email
Weekly
Project Team 1 &2 Project Manager Project Team 1 &2
Team Lead
Meeting Minutes Status Report Meeting Minutes
Email Face to Face
Monthly
Team Lead
Weekly
Team Lead
Communication distribution within the TMMPM project can take place in many forms though its highly suggested that regular meetings should be adopted since not only do they serve to build stronger relationships among personnel and stakeholders, they also enable the stakeholders to interact with each other and get a true feeling for how a project is progressing. This measure will also serve to safeguard cases where department heads feel that their department is the most important by nurturing personnel bonding and interpersonal skills. Once the Stakeholders and personnel establish good business relationships, they wont necessarily have to argue over a matter but instead will look into the issue from a professional perspective and arrive at a valid conclusion.
Performance reporting might have been overlooked thus leading to both the project leaders and respective stakeholders making decisions on assumptions which merely aligned to the projects main objectives. This measure might also have contributed to the fact that technical skills in some departments lacked but such cases went unaddressed. This together with other drawbacks eventually culminated to failure. In the case of the TMMPM project, performance reporting should be carried out through the following methods: Status Reports These will serve to highlight where the project stands at a specific point in time as well as address scope, time and cost goals. Progress Reports These will serve to describe what the TMMPM project team has accomplished over a given period. It will feature weekly progress reports on each departments activity as well as consolidated reports for higher ranking stakeholders such as managers and department heads. Forecasts These will purely serve to predict future project merit and progress based on past information and the current business trends. This will be helpful since department heads of the TMMPM project will have a forecast on things to achieve therefore issue better tasks and decisions. Issue Logs These will serve to address matters that may impact the overall progress of the project. They will also serve to document and monitor the resolution of the arising issues within the TMMPM project. The Following table shows an example of a monthly status report that will be essential towards addressing effective performance reporting in the TMMPM Project.
CE00348-3-PM
30
Project Monthly Status Report
Project Team: Prepared By: Date: Reporting Period :
TMMPM Project Project Manager. 4th- September 2012. 4th August -3rd September 2012.
Executive Summary Controlled Schedule [X] Caution Critical Reasons for Deviation The project is progressing at a stable pace and everything is on schedule. A lot of expenses within the milestones tend to use more money than was originally planned. The Scope of the TMMPM Project is well under control and every milestone has been met successfully. Successive Testing is being carried out and all is under control.
Budget [X]
Scope
[X]
Quality
[X]
All in all, improved performance reporting will lead to better forecasting thus enabling the employees to understand where the project stands at a specific point in time and business trends that might implicate the normal project pace. Introduction Rewards & Bonus Schemes. In the case of the TMMPM project, project failure might have come up due to lack of employee motivation as a component of human resource management. The company might have been making profit but failed to reciprocate to its employees.
CE00348-3-PM
31
Introduction of a rewards and recognition scheme by offering compensational benefits and appraisals to staff that have shown a notable degree of performance within the course of the project will greatly help salvage the failing project since it offers the employees the Feel Good Feeling and the need to better their best. Reward schemes in the TMMPM project could be implemented through the introduction of an early completion bonus scheme which serves to recognize achieving a given project milestone earlier than stated. This measure will not only realize hard work, it will also serve to foster cross level cooperation among the stakeholders at TMMPM since they will all be working towards a mutual goal. Aside this, introduction of performance appraisals in the TMMPM project will serve to ensure that employees are motivated to work hard and at the end of the day align their collective human resource team with the daily business needs. In general, TMMPM should strive to ensure that they have an organizational structure that not only fosters good communication but also one which is able to highlight the processes required to ensure timely and appropriate generation, collection, dissemination, storage, and ultimate disposition of project information. Industry Examples In 1990 due to liberalized government policies of various countries, human resource started floating from one country to another thus leading to diversification of workforces and cross culture. This phenomenon in turn yielded the need for HR professionals to play the major role in coordinating all the major processes within the workforce of an organization in order to observe accountability (Yasmeen Begum, 2009).
CE00348-3-PM
32
10. Project Quality Management

10.1 Assumptions
The Following are conclusive assumptions drawn from the case study regarding the development and management of the TMMPM project. Top Management executives failed to lead by example thus not fostering the need to lay emphasis on quality. The Employees did not receive regular training on the methods and concepts of Quality management. The TMMPM project overlooked customer satisfaction as a component of measuring both growth and service delivery. The TMMPM working culture wasnt favorable in ensuring that the employees worked collaboratively in order to offer quality services. The TMMPM project overlooked cost of quality as a whole.

10.2.1 Issue No. 11 The testing plan was not developed yet
Having been operational for 9 months and failing only into its last quarter of operation, one can rightfully conclude that the TMMPM project sure lacked an efficient testing plan if any. This in turn led to the project team overlooking the quality of services they offered to the market thus leading to project failure. Testing serves to ensure that the services and products offered are valid and meet a specific degree of conformance before being rolled out to the market. This unit might have been overlooked due to its low affinity of interest during service delivery since most companies tend to save money on testing as well as the added fact that the TMMPM project had a prosperous sail for 3 business quarters.
10.3 Remedy Solution

Develop an Efficient Test Plan One of the reasons that led to the failure of the TMMPM project was due to lack of a Test Plan. This in turn meant that the company was actually rolling out services that failed to meet their customers requirements and expectations.
CE00348-3-PM
33
In every service industry, top priority is dictated by the need to establish long term customer satisfaction. This is essential since it in turn builds up credibility among customers thus turning them into loyalists for your services. This step is quite essential since the TMMPM project will yield a base operating market for their services thus allowing them to analyze the market better in cases where they might need to test new services or perhaps even roll out a completely new product all together. It should be noted that quality is also dependent on external factors such as Competition. Its important and mandatory to ensure that the TMMPM project doesnt overlook this factor since it can greatly affect sales and customer loyalty. Aside this, its important to make sure that the quality of the services being offered by the TMMPM project meet customer expectations and yield overall improvement. Good quality will in turn address the cost of poor quality if well analyzed. In the case of the TMMPM project, testing should be done systematically beginning with the creation of a good quality plan in the planning phase of the project, followed by quality assurance in the execution phase and lastly effective quality control that serves to verify service delivery in general. Observing Hardware and Software among the opportunistic Technical risks that might affect overall project development, its necessary to address the two issues. In the case of the TMMPM project, the following steps are going to be taken in order to address quality: Quality Planning This will involve the development of a plan that will describe the approach to be taken while testing, as well as the individual processes and steps that are set to be carried out within. Quality Assurance This measure serves to ensure that the right product/ service is being developed. Its usually characterized by validation. Quality Control This measure serves to ensure that the product is being developed right. Its usually characterized by product/ service verification. A good quality plan should at least highlight the following: Describe the product Includes product description, users and objectives. Product Plans This mainly specifies the approach to be taken with the product, critical dates, responsibilities, checkpoints and further release plans Process Descriptions and Quality commitments.
Asia Pacific Institute of Information Technology 34
CE00348-3-PM
Development and Assurance Processes. Quality actions planned In the case of the TMMPM project, we are set to focus mainly on Unit and integration testing since we are testing hardware. Roles & Responsibilities In the case of the TMMPM project, the responsibilities of all stakeholders and personnel working on the project.
The Following table illustrates the measures that have been undertaken in addressing quality.
Table 14 TMMPM Software Quality Measure
Quality ID Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Q11 Q12 Q13 Q14
Software Quality Functionality Functionality Functionality Functionality Functionality Functionality Functionality Availability Performance Reusability Security Security Usability
Quality Measure Verifying Web-Front-End Checking the Database Update Project status Check Finance Records Generate Sales Reports Generate Progress / Financial Report Calculate Total company Expenses The system should be up and running 24/7 System should display a minimum of 97% accuracy Should be able to update the inventory information in database as POS system Transactions must be secured using SSL protocol System should be protected from security vulnerabilities and violations A user-friendly system must be designed and developed considering ISO for HCI standards Documentations and plan should follow PMI standards
Quality Role SDM Team 1s Leader Project Manager Project Manager Team 2s Leader Team 1s Leader Procurement Management Quality Assurance Team 1s Leader SDM SDM SDM SDM Project Manager
Since we are carrying out Hardware testing, unit testing and further integration testing is best suited in the case of the TMMPM project. Unit testing will seek to ensure that each individual component that is present within the system is working before implementing integration testing. This approach is also best suited due to the high number of internetworked work group computers at TMMPM.
CE00348-3-PM
35
Table 15 shows how the identified project standards are achieved through performing a Quality Assurance Activity in the process of addressing both unit and integration testing.
Table 15 Quality Assurance Activity
Process Quality Standards / Stakeholder Expectation Verify Web-Front-End Checking the Database Update Project status Check Finance Records Generate Sales Reports Generate Progress / Financial Report Calculate Total company Expenses The system should be up and running 24/7 System should display a minimum of 97% accuracy Should be able to update the inventory information in database as POS system Transactions must be secured using SSL protocol System should be protected from security vulnerabilities and violations A user-friendly system must be designed and developed considering ISO for HCI standards Documentations and plan should follow PMI standards
Quality Assurance Activity Unit Testing, Integration Testing Unit Testing, Integration Testing Unit Testing, Integration Testing Unit Testing, Integration Testing Unit Testing, Integration Testing Unit Testing, Integration Testing Audit project schedule plan, Audit monthly status report Functionality Testing, Performance Testing Performance Testing, Load Testing
Frequency As needed As needed As needed As needed As needed As needed Once a month Once As needed
Compatibility Testing
As needed
Functional Testing, Conformance Testing
As needed
Functional Testing, Conformance Testing
As needed
Conformance Testing
As needed
Audit Project Documentations
Once a month
In order to further improve the quality of the project, a defect management mechanism will be implemented. The Table 16 illustrates how the process will be carried out in the case of the TMMPM project.
Table 16 Defect log sample
Defect ID CE00348-3-PM
Description of
Severity
Priority
Assignee
Current Status 36
Staffordshire University/ Level 3 Defect The application cannot register new users within the system successfully
D1
Critical
High
Elham
Error addressing still pending
Quality Control should also be addressed in order to ensure that each process that occurs within the course of the project is monitored and conforms to the standards that have been set during the planning phase of the project. Table 17 illustrates a simple test case to be used in carrying out quality control.
Table 17 Quality control sample case
Business Case Name of Scenario Tester
Test Script
How the Script is to function Login to the system successfully
Logging into the System
Mashid
Instruction 1
How the Script actually Functions Logged into the system successfully
Status of Test
Pass
Above all, quality determinants such as communication, competence, courtesy and reliability should be highly observed since the companys main goal is to net in as many customers as they can from the market in order to maximise on profits and recover from the current state in which they are failing. Industry Examples After a revision of failed projects in the First World War, quality inspection became more commonplace in manufacturing environments and this led to the introduction of Statistical Quality Control (SQC), a theory developed by Dr. W. Edwards Deming. This approach to quality provided a statistical method of quality based on sampling. Where it was not possible to inspect every item, a sample was tested for quality. The theory of SQC was based on the notion that a variation in the production process leads to variation in the end product. If the variation in the process could be removed this would lead to a higher level of quality in the end product.
CE00348-3-PM
37
11. Project Procurement Management

11.1 Assumptions
The team working on TMMPM failed to conduct a good requirement specification statement. The previous team assigned to TMMPM project failed in conducting a correct procurement plan.

All of the problems listed under this section have a common feature as they are in relation with purchasing or obtaining products or results or services needed from outside of the project team to perform the work. Hence, accordingly the team found project procurement management to be suitable domain to recover for the issue number 7, 8, 12 and 15. The team take in mind that procurement is one of the key processes of all types project which undergoes significant alterations and changes in the organizations and has moved from a reactive activity to a strategic one, contributing to a firms competitive success (Humpreys, 2001).
11.2.1. Issue No. 7 The PC and server hardware technical specifications were constantly being changed to suit new or added requirements. This issue is caused by the constant change of specifications trying to fit the new added requirements; usually these kinds of problems are not surprising as even the current IT projects normally are faced with them because there is also a constant change in the technology too. The project team that was working on the TMMPM could have come up with a good requirement specification in the early stages of the project development to reduce the cost and risk that they faced. The concept of constantly changing requirements means more money and this can cause over budget. This would have been avoided in the initiation and planning of the early stages.
11.2.2. Issue No. 8 The hardware and software delivery was still being negotiated while there were only 3 months to complete the project.
This issue relates completely to project procurement management when highlighting the existence of delivery concept and negotiation concept as it is still going on, the teams interpretation is that this issue belongs to the stage of conduct procurements and applying proper strategies at this stage would recover it. This problem could be a result of not properly planning and incorrect procurement conducting procedures as this interpretation is that negotiation is still in full operation.
11.2.3. Issue No. 12 The current network infrastructure needed a major upgrade to support the PCs and servers for the new system. In this issue, it seems like the initial plan was to keep on with the current infrastructures, though the current network substructure is not able to support new PCs and servers and it needs to be upgraded since it is also in contrary with one of the critical factors required to ensure project success. This problem also comes under project time management which involves the processes required to ensure timely completion of a project (Kathy Schwalbe, 2010). If the project team achieves timely completion of a project then this problem would have not occurred in any chance. This problem actually falls through the stages of procurement management as it is important to appreciate it as an immediate need of the project. The project team must know their PCs and servers technical specification in order to be able to identify the characteristics of what kind of network infrastructure is needed for the new system. This would have been done in solution to issue number 7 and 8 alongside with the project requirement. Project team will spend more time on planning since the project is already running out of time and therefore cannot afford time to redo the whole process at the late time. This planning would be followed by assessment and funding of the project and then next would be the conduct procurement. Precise monitoring and control using appropriate strategy has to be taken to administer this procure. The team recommends that the network team should be checking and reporting the performance of work constantly. Therefore, project teams procurement of the network infrastructure will be successful until the closing stage of the procurement management.
CE00348-3-PM
39
11.2.4. Issue No. 15 It was generally felt that the in-house developed system was not very different from a vendor developed software, e.g. SAP The interpretation of this issue is that, the software is already bought (or is ordered and being developed), however the purchased product seems to be similar to companys own developed system. This is a problem with two different perspectives, one would be that project team have purchased what they already had (or could have by minor customizations) which is a blunder; for one reason it is a waste of budget. Other is what have been ordered were not delivered, for example the team might have ordered a system (similar to their developed one but) with new features and functions, whilst the provided system does not bring any of these and its almost the same as what they had. Interestingly both situations could be avoided by employing proper procurement strategy. For the first perspective where purchase was not necessary, employing appropriate techniques such as make-or-buy analysis at the stage of procurement planning would avoid it.1 For the second case however, project team could reduce the likeliness of its occurrence by using techniques like independent estimates and proposal evaluation at the stage of conduct procurement. In either situation, the issue now belongs to the stage of Administer Procurements since the procurement is already made.
11.3 Remedy Solution

As the proposed solution to issue no. 7, the team will suggest a redetermination of project specification, like for the project scope management where it includes the processes involved in defining and controlling what work is or not included in a project (Kathy Schwalbe, 2010). It ensures that both the project team and the stakeholders have the same understanding of what requirements the project will need and what processes the project team will use to produce them. The reason behind this proposal is that, since the constant changes in the requirements are likely to happen, even in reality, the specification of the hardware should have been
1
It is important to note though, this problem could be avoided at the stage of scope management as well.
CE00348-3-PM
40
determined in a way that it will be more adaptive to changes. Therefore, the team will produce or re-produce a new procurement plan for the PCs and servers. Table 18 shows the plan based on the PMBOK guidelines:
Table 18 PMBOK guidelines on Procurement Plan
PLAN PROCUREMENTS Inputs: Scope baseline Requirement documentation Teaming agreement Activity resource requirement Cost performance baseline Enterprise environmental factors Tools and Techniques: Expert judgment Outputs: Procurement statement of work
The team has also prepared hypothetical specification for PCs and servers which is based on the case study; it is shown in the Table 19:
Table 19 Hypothetical Specification for PCs and Servers
Desktop PCs Number of PCs required (each department) Information System (IS) Accounting and Finance Engineering Materials (Contracts) Law Public Affairs Payroll Human Resources Planning Total 95 72 109 38 7 12 11 10 6 360 Technical Specification Intel Pentium 4, 2.2Ghz 1GB DDR2 RAM 30 GB Hard disk ATI X RADEON1400 256MB Graphic Card Integrated Sound Card Intel LAN Card D33682 Windows XP professional Edition SP2 Apache Tomcat 6.X MySQL 4.X PHP Admin 3.X Microsoft Office Enterprise Edition 2007 Internet Explorer 7 and above
CE00348-3-PM
41
Staffordshire University/ Level 3 Servers Web server Production IBM XEON 4.3.0 GHZ 4 GB DDR2 RAM 80 GB SCSI Hard Drive Web Server = 2 D/B Server =1 File Server =1 Ethernet Connection 100 Base T Web Server Apache 6.X Linux Red hat Version 9.0 Perl 5.6.1 PHP 4.2.3 Backup MySQL 4.X HTTP Analyze 2.4 D/B Server =1 File Server = 1 SSH 1.2.7 PHP My Admin 3.X Java EE 6 SDK Python 2.X File server - DB server IBM XSERIES 335 XEON 2.4 GHZ 4 GB DDR2 RAM 300 GB SCSI disk drive ATI X RADEON1400 256MB Graphic Card Intel LAN Card D33682 DVD-RAM SATA DRIVE Dual hot-swap power supplies 1-20 backup disks Linux (REDHAT version 9.0) installed Battery Backup Backup servers Dual Xeon Pentium 4.3 GB DDR2 RAM ATI X RADEON1400 256MB Graphic Card 300 GB SATA2 disk drive Intel LAN Card D33682 Dual (redundant) power supplies DVD RAM SATA drive Linux (REDHAT version 9.0) installed Battery Backup
The next process in procurement management involves deciding whom to ask to do the work, sending appropriate documentation to potential sellers, obtaining proposals or bids, selecting a seller and awarding a contract (Kathy Schwalbe, 2010). Table 20 shows procurements conducting according to the PMBOK methodology.
Table 20 Conduct Procurements
CONDUCT PROCUREMENTS Inputs: Source selection criteria Procurement documents

Qualified seller list Tools and Techniques: Bidder conferences Procurement documents Outputs: Procurements documents Resource calendars Selected sellers Procurement contact award Referring to the Table 20, the team will be required to investigate why the negotiation is still going on and where the potential problem could possibly be, by doing this, theres an obvious need to study the procurement documents, source selection criteria and qualified seller list. Then the team can use the procurement negotiations techniques to overcome the problem and if the situation is tied to extend that negotiations wont be helpful as the team need to suspend current negotiation and move on to find the next best seller. Putting concern on the available time, the team suggests using bidder conference technique in order to select seller as soon as possible, since the team is strongly trying to win the situation over negotiation. Two of the main outputs of this process are a selected seller and procurement contract award. Throughout the investigation, project team has found an interesting reference that has addressed a similar case, see (Cagle, 2003). In this book within the chapter for recovering project from technical problems, one of procurement problems stated as: The materials were not proper for the processes and the product(s) and/or did not meet the requirements Based on the explanation and case studies given there, this issue has fallen in place with aforesaid problem. Inevitably project team proposed strategy to solve this issue is based on recovery plan suggested in (Cagle, 2003, p.140); (see Figure 6).
CE00348-3-PM
43
Figure 7 Solution framework for issue No.15 (Source: Cagle, 2003, p.140)
CE00348-3-PM
44
The case study hardly provides any information on this particular matter and assumptions seem to impair scope of the project. Therefore, the team can hardly provide any concussion result No matter what the details are. The general strategy is represented in Figure 6. Required input, tools and techniques and expected outputs of this process listed in Figure 7, based on PMBOK.
Administer Procurement
Input:
- Contract
- Performance report - Procurement documents - Project management plan
Tools and Techniques:

- Contract Change control system - Procurement performance review - Claims administration
Outputs:
- Procurement documentation updates - Change requests - Project management plan updates
Figure 8 Input, tools and techniques required for solving issue no.15
CE00348-3-PM
45
12. Individual Reflections

12.1 Elham
Project management in today's world is an essential part of each project. This has been cleared before throughout my academic life in APIIT. But the Project Management module gave me an in depth sight of what is project management in its core. We have started to work on the assignment with a relative shallow depth of view as we have had not yet studied the full knowledge areas and processes involved with a detailed project management process. So we had to complete the work at each phase in accordance with our knowledge. The first part we have started to work on was to come up with a project charter. This has happened through several brainstorming sessions with the group members. At first, Total Materials Management and Planning (TMMPM) Project seemed to be not very challenging to recover from a total failure. But this view of mine has been changed as we start and progress. The next step was to divide the 15 stated issues in the case study into only six selected knowledge areas. These knowledge areas would help giving us a guideline to take corrective actions toward the recovery of the project from disaster and loss of budget and effort. The process of dividing the fifteen issues, however, turned out to be a very cumbersome challenge. It took us two sessions to divide them. This means that we should give a reason why we think we should handle a problem using a specific knowledge area. A very good reason could be the similar issue and the solutions taken by other organizations and to see if it was successful or not. We made a confirmation with our lecturer Ms. Tham Hoong Ching and she advised on being able to justify our reasons strongly, why we think that those particular problems should be handled using a specific knowledge area of project management. The challenging part of the assignment in terms of group work is that as a project manager, I had to coordinate the work, delegate the tasks and integrate them. However, we did manage to coordinate the group discussions and were able to come up with a proper solution for TMMPM. All of us did spend a considerable amount of time on this assignment, so as a group member, I guaranteed that our work is not the last-minute work. I was also responsible for finding solutions for issues regarding Project Cost Management as well as Project Scope Management.
CE00348-3-PM
46
Project scope management is one of the early stages of project management. Project initiation determines what the project will do, whereas planning is needed to determine how it will be done. I have found the scope management a cross between initialization and planning that determines exactly what needs to be done, that is, what is included in the project and what is not. This exercise gave me the chance to produce Project Charter and Work Breakdown Structure (WBS) which both are corner-stones of every project. Referring to one book was not sufficient for me to produce the solutions. So, I thoroughly searched project management books in the library. Among the books that I have skimmed through, Kathy Schwalbes Information Technology Project Management book was a good and helpful one. The contents inside were not based on another methodology but elaborated on PMBOKs methodology and techniques. So, it gave me a clear insight over the
knowledge areas of PMBOK and how I could apply these techniques to produce viable solutions for TMMPM. To sum it up, this module together with its assignment, which was to recover a project from total failure, gave me a very good insight about the project management different knowledge areas, their processes and procedures, tools and techniques and furthermore, the usage of them in some of the most successful organizations of the world. This will definitely help me in my future career, either as an employer or a manager, to better understand the nature of the projects and deal with the issues and problems involve with them.
CE00348-3-PM
47
12.2 John
In the course of undertaking this assignment, I surely learnt a lot about project management. From the bodies of knowledge that govern it to the individual phases and lifecycles involved during management. The assignment not only enabled us to relate real-world problems in project management and finding viable solutions to each one of them, it also enabled us to develop a broader sense of critical thinking and analysis. In the course of addressing the case study in this assignment, I was able to nurture my interpersonal skills with my group members who proved to be co-operative and well open minded towards idea. Its certainly due to the fact that we were easily able to relate to each others views that we successfully completed the assignment and even had time for further recap. Over the course of the project we had a smooth sail as a group. We were able to divide the work to be covered evenly and we could occasionally offer further assistance and a sense of motivation to each other from time to time. Whenever we felt that the progress of the project needed to be stepped up or when a conflict of interest arose, we held brainstorming sessions which proved quite effective since we were able to confer our ideas seamlessly and at the end of the day come up with an adept turning point. Its through the appreciation of each group members effort that we were able to pursue the assignment at a steady pace and with ease. Each member was able to bring their best foot forward, collaborate effectively and at the end of the day yield above par. In the course of the assignment, we were able to get a sense and feel of issues that encircle project management in the real world and this greatly proved to be invaluable to each individual. The assignment also enabled us to have an in-depth analysis on the major constraints that influence a projects success or failure. We were able to identify a number of factors that might have caused the TMMPM project to fail and likewise came up with rational solutions to each one of them. We aligned our solutions to focus on the key areas within the project that had a higher priority in order to recover the failing project as fast as possible. I was personally tasked with the mandate of identifying key solutions in the fields of quality, Human Resource Management and Communication. During this process, I got to learn a lot about quality management, its aspects, domains and even reviews on how it can be improved in the future as a factor of ensuring that a company produces its best output for the market.
CE00348-3-PM
48
In the course of my research, I was able to have a clear picture of how the human resource department carries out their tasks and how they also strive to ensure they hire the right person for the job. I also noted that this was perhaps the foremost step in ensuring the smooth running of any given project within an enterprise. Having the right team not only ensures that the project will be effective; it also fosters good communication internally. During the course of this assignment, I was also able to ascertain a few notable trends that are taking place in the modern day market in the fields of quality and human resource. The key observable trend was the fact that most companies are actually outsourcing both services to third parties for the sole purpose of ensuring that they are able recruit staff from a broader scope in the case of human resource and achieve unbiased testing of their products in the case of quality management for manufacturing companies. This trend is slowly picking up in the field of project management and might actually be the order of the day in the future given that companies are still able to achieve their goals within time and within their budgetary confines. All in all, I would really like to appreciate the moral support of our Lecturer during the course of this assignment. She really played a timeless role towards bringing our project to fruition through offering guidance and routine counsel on our research. Working with my team members - Elham and Mahshid was really quite a noble experience to say the least!
CE00348-3-PM
49
12.3 Mahshid
During doing this assignment, a clear picture of what the Project Management is all about is given to me. Several project management books and websites were studied in order to find about techniques and methods to manage the projects best ever. We used Project Management Body of Knowledge (PMBOK) as most popular project management practices. After choosing the methodology, six major problems have been identified and classified using PMBOK knowledge area. Later on, each person in the group took two problems according to the workload matrix and work on them. There were 2 types of project management problems in this assignment that I was responsible for them, Project Procurement Management and Project Risk Management which I have prepared proposed a solution for them. Planning a proper risk management plan was of the highest priority. The risks with the highest likelihood and consequence should have been identified in the minimum period of time and the preventive and corrective actions needed to be identified and documented for each risk. To identify risks I needed the information on the work has been done so far and current state of the project. The 3rd and the 4th editions of Project Management Body of Knowledge (PMBOK 2004 & 2008) were my guideline through this way. But this was not enough. Using only one source wasn't proving the correct path to handle the project's risk management issues. Another reliable source was needed to check whether the current steps have been used by other organizations and they have been proven to be working well. So, the next step was to find a trustworthy source to help making me sure of my guidelines. My extensive research guided me to the one of the leading organizations in the area of science and technology. I have learned a lot from reading the slides and PMBOK and through research I've gain this insight that these management processes are well trustworthy and has been tested in some of the most critical and even dangerous projects and therefore, considering each project's characteristics, they can be of great help to any project manager to help foretell and prevent negative impact of the risks of any magnitude. project procurement management, being the last stage if the knowledge areas of project management, includes the processes required to acquire goods and services for a project from outside the performing organization (Kathy Schwalbe, 2010). It is to aid the process of purchasing goods and services from external suppliers. This taught me that project
procurement managements impact on the performance of the project development is critical in which it can originate and recover differences/deviations. As the learning outcome of this assignment, I already know that managing a project plays the most significant role in the success of failure of the project. Besides, there are different areas and points of views need to be managed and controlled in a project. It is too important to consider all these areas, otherwise, project will fail or the final product or event does not meet requirements that are defined in the initiation of the project. There are some techniques and procedures available to help managing and controlling project progression and completion. However, a good project manager knows when and how to use some methods in order to control some factors in the best interests of meeting project objectives. Finally, I would like to appreciate our lecturers in this module, for all their efforts and great lectures. Tutorial classes help a lot to learn and realize project management concepts, tools and techniques.
CE00348-3-PM
51
13. Conclusion
An in depth look at project management has not only enabled us to understand the factors that influence a project, it has also enabled us to come up with solutions in bid to address the shortcomings highlighted in the case study. We did an in-depth analysis of the reasons that might have caused the project to fail and likewise identified solutions to the problems. This process couldnt have been possible had we not taken the right approach which was first to categorize the problems into scalable domains then seek to address them separately. A deeper understanding of the principles of project management enabled us to identify the methodologies used in project management and we settled for the most appropriate which in this case, it was PMBOK. We studied the knowledge areas and routines involved herein and thus identified the most effective way of addressing the problems in the case of the TMMPM project. The project charter and work breakdown structure proved perhaps to be the most important tools during this process since they offered a clear point of reference to the tasks that we had identified during the planning phase and it also further enabled us to address the problems in a systematic order. It was important to make sure that the problems were addressed in systematic fashion in order to prevent idea collision which would have stalled successful completion of the project. All in all, its strongly believed that the solutions highlighted herein are appropriate and could really help save the TMMPM project. Major effort was put in addressing risk management since it was strongly felt that it was perhaps the factor that needed to be addressed with greater concern. Understanding risk within any organization is important since it highlights situations which the project might be subjected to in case any factor that influences the well-being of the project at hand is overlooked. Other than that, an in-depth study of the other factors such as scope management, cost management, communication, procurement and quality management also proved to be effective and of concern since in the case of the TMMPM project, the primary obligation was to revive the project at the least cost and in the least amount of time.
CE00348-3-PM
52
14. Appendices
14.1 Appendix A: Project Charter
Project Name:
Total Materials Management and Planning (TMMPM) System

VERSION: [1.5] REVISION DATE: [August 2012] Approval of the Project Charter indicates an understanding of the purpose and content described in this deliverable. By signing this deliverable, each individual agrees work should be initiated on this project and necessary resources should be committed as described herein.
Approver Name Title Signature Date
CE00348-3-PM
53
Project Start and Finish Date 10 July 2012 to 9 October 2012 Project Statement Implementing and deploying a new automated system to assist the manner in which materials and services are contracted and procured within the various departments in the office. This is to replace the current manual system. Project goals, business outcomes, and objectives This section describes the project goals and links each of them to related measurable project objectives. In addition, business outcomes are stated.
Table 21 Project goals, business outcomes, and objectives
Goal Enhance the quality of conducting materials and services within various departments in the office
Efficient use of resources
Objective - To automate the current work of contracting and procuring materials and services - Remove the delay in contract selection, approval and award processes. - Create a central repository to store and access information - The new system must be integrated with the current existing IT infrastructure -To assist the manner in which materials and services are being contracted and provided at the company - Involve all the departments - To be provided to all employees (with vary access privileges) - Automate the process of contract selection, approval and award processes. - Allow all procedures and processes to take place online - implement backup/recovery features for new system - Parallel use of both systems during the cutover (switching from old manual to new automated system).
Business outcome Implementation and deploying of new system Materials Management and Planning (TMMPM)
To setup a standard, support and guideline for material management
Achieve corporate recognition activities
Reduce the cost and risk of manual system
Discontinue manual system
Ensure stability and integrity of new system
CE00348-3-PM
54
Project scope Currently all the procedures of procuring services and materials are handing manually. In order to reduce the cost and risk of manual system, enhance the quality of existing processes and to assist the manners of conducting procurement within various departments in the office, a new system is to develop that particularly automates the process of contract selection, approval and award processes. This is to allow all procedures and processes to take place online, all the employees of all departments are to access the new system and be provided with standard, support and guideline for material management. The focus of project is on quick delivery and efficient use of resources while ensuring stability and integrity of new system. Critical Success Factors This section describes the factors and characteristics that are deemed critical to the success of the project, such that, in their absence the project will fail. the current IT infrastructure must support this new system all employees must have access to this new system (access privileges will vary) the approvals must be online and the manual system will be discontinued the cutover - (old manual system to new automated system) must be in parallel backup/recovery must be essential to ensure stability and integrity Milestones This section lists significant points or events in the project (such as the phases, stages, decision gates, and approval of a deliverable) which their failure or delay has huge impact on project success.
Table 22 TMMPM Milestones
No. 1 2 3 4 5 6
Milestone Complete Initiation of the TMMPM Complete Design Complete Prototype Development Complete Documentation Complete Cutovers Project Wrap Up
Targeted Duration (Days) 22 13 15 11 18 12
Targeted Finishing Date Mon 8/6/12 Fri 8/17/12 Mon 9/3/12 Fri 9/14/12 Thu 10/4/12 Wed 10/17/12 55
CE00348-3-PM
Deliverables Deliverables are keys to the achievement of the stated objectives. Verifying completion of project is upon achievement of deliverables. Automated online system for material management Central repository to store and access files Timing contract management and approval system Guideline, standard and support for material management User access privileges for all employees 360 new PCs, 2 web servers, one file server and one database server each with one backup server. Project Approach This section is a highlight of major steps to be taken in this project from initiation to closing phase of the project. Conduct feasibility study Create business case Collect stakeholders requirements for the system Outline project management plan Estimate costs, risks and resources to be acquired Identify risk, change management plans Develop software Test the software Make necessary corrections Implement the system in the organization Train the personnel to use it Cutover parallel use of manual and new automated system Discontinue the manual system upon successful cutover process Maintain the new system
CE00348-3-PM
56
Project Organization
Figure 9 Organisation Structure for TMMPM Project
CE00348-3-PM
57
Roles and responsibilities

Activity/Team Role Sponsor Project Manager (PM) System Developer Manager (SDM) Leader Bruce Wayne Elham Member Report to ---Project Steering Committee Justin Nicole *others Report From Elham John, Tony, Tom, Mark Mahshid, Sam, Sara Responsible/description -Approve or reject the scope, cost or time change request as appropriate -Evaluate need for project scope change -Evaluate deliverables -Responsibility of the planning, execution, and closing TMMPM project -Manage the whole system Development -Expert in managing system development -Used to be a senior programming -Strict person that can manage team well. -Manage the TMPMM function -Most of the members are from the IT department. - Mahshid is one of the accountable people in managing the materials for this organization. Shes been assign to this group in order to give opinion how materials can be manage with her experience. -since Mary and Adam are both from different working environment and expertise, they might have challenge. (Need to be monitored) -Manage the TMPMM function -Responsible for testing the system. -Some of the members from the procurement department will join this team in order to test the system. -Responsible for procuring related items that is needed to runs the TMPMM. -Have a strong communication with hardware and software vendors. -Responsible for improving and maintaining quality for the system. -Responsible for configuration of the system after the TMPMM is completed.
John
Elham (PM)
Team 1(SD)
Mahshid
Adam Mary *Other s
John (SDM)
Team 2 (SD) System Testing Procurement Management Quality Assurance Installation (Hardware/Software)
Sam Sara
Tone *Other s Mike Reza *Others Reza *Others Joey *Others Sina *Other
John (SDM) John (SDM)
Tony Tom Mark
Elham (PM) Elham (PM) Elham (PM)
Table 23 Roles and responsibilities
CE00348-3-PM
58
Project facilities and resources Financial Performance measuring techniques such as trend analysis, variance analysis or EVA to assess the impact of cost changes, we propose to update the total budget to RM 1,030,920 Material This section represents an outline of the materials required to complete the project
Number of PCs required (each department) Information System (IS) 95 Accounting and Finance 72 Engineering 109 Materials (Contracts) 38 Law 7 Public Affairs 12 Payroll 11 Human Resources 10 Planning 6 Total 360 Servers Production Web Server = 2 D/B Server =1 File Server =1 Backup D/B Server =1 File Server = 1 6
CE00348-3-PM
59
14.2 Appendix B: Work Breakdown Structure

In order to effectively manage the sequence of work required to complete this project, we will be subdividing the project into individual work packages. This will allow the Project Manager become more effective in terms of managing the projects scope as the team works on the tasks required for project completion. The project is broken down into seven phases: design, prototype development, quality assurance, create system documentation, implementation, cutover from manual to new system and discontinue manual system. Each of these phases is then subdivided further down to work packages and further to tasks.
CE00348-3-PM
60
TMMPM Project
Initiation
Design
Prototype Development
Quality Assurance
Create system documentation
Implementation
Cutover from Manual to New system
Discontinue Manual system
Business Case Analysis
Web User Interface
Web Front End
Web Front End
Assemble Tech Specs
Develop Implementation Plan
Create training materials
Verify New System
Project Charter Development
File server and Database
Develop System Flowcharts
Hardware
Train users
Monitor New system
WBS Development
Reports
Reports
Reports
Deliver Source Code
Packaged Software
Project Wrap-up
Planning
Complete System Documentation manual
Installation
Shut down the manual system
Figure 10 WBS, phases and work packages
CE00348-3-PM
61
WBS Coding system complete structure of phases, work packages , task and subtasks. TMMPM Project
1. Initiation 1.1. Business Case Analysis 1.2. Project Charter Development 1.3. WBS Development 1.4. Planning 1.4.1.1. Scope Management Plan 1.4.1.2. Risk Management Plan 1.4.1.3. Quality Management Plan 1.4.1.4. Human resource and Communication Plan 1.4.1.5. Cost Management Plan 1.4.1.6. Procurement Management Plan Design 2.1. Web User Interface 2.1.1. Functional Specifications 2.1.1.1. Create User Interface Mock-ups 2.1.1.2. Conduct Design Review 2.1.1.3. Deliver Final Functional Specs 2.1.2. Technical Specifications 2.1.2.1. Develop Tech Specs 2.1.2.2. Review Tech Specs with Project Team 2.2. File server and Database 2.2.1. Technical Specifications 2.2.1.1. Develop Tech Specs 2.2.1.2. Review Tech Specs with Project Team 2.3. Reports 2.3.1. Functional Specifications 2.3.1.1. Collect Requirements 2.3.1.2. Define Materials 2.3.1.3. Define Contracts 2.3.1.4. Define Approvals 2.3.1.5. Design Reports 2.3.1.6. Review Report Design with Project Team 2.3.1.7. Deliver Final Functional Specs Prototype Development 3.1. Web Front End 3.1.1. Code Web Pages 3.1.2. Conduct Unit Test 3.1.3. Review Web Page design/functionality 3.2. File server and Database 3.2.1. Identify table relationships 3.2.2. Build database tables 3.2.3. Review Tables with project team 3.3. Reports 3.3.1. Code Reports 3.3.2. Conduct Unit test 3.3.3. Review Reports with project team Quality Assurance 4.1. Web Front End 4.1.1. Verify design and functionality 4.1.2. Perform Integration Test 4.1.3. Perform User Acceptance Test 4.2. File server and Database 4.2.1. Verify design/data elements 4.2.2. Verify relationships 4.2.3. Perform Integration Test 4.2.4. Perform User Acceptance Test 4.3. Reports 4.3.1. Verify design and functionality 4.3.2. Perform Integration Test 4.3.3. Perform User Acceptance Test Create system documentation 5.1. Assemble Tech Specs 5.2. Develop System Flowcharts 5.3. Deliver Source Code
2.
3.
4.
5.
CE00348-3-PM
62

5.4. Complete System Documentation manual 6. Implementation 6.1. Develop Implementation Plan 6.1.1. Construct Timeline 6.1.2. Identify Team 6.1.3. Identify Components 6.1.4. Finalize Plan 6.2. Hardware 6.2.1. Determine hardware needs 6.2.2. Make Hardware selections 6.2.3. Purchase hardware 6.2.4. Deploy 6.2.5. Perform System test 6.2.6. Verify production readiness and signoff 6.3. Packaged Software 6.3.1. Determine software needs 6.3.2. Make software selections 6.3.3. Purchase software 6.3.4. Deploy 6.3.5. Perform System Test 6.3.6. Verify production readiness 6.4. Installation 6.4.1. Convert hardware to production-ready status 6.4.2. Convert packaged software to production ready status 6.4.3. Install new programs into production environment 6.4.4. Verify code 6.5. Initiate limited production run for user acceptance Cutover from Manual to New system 7.1. Create training materials 7.1.1. Assemble Functional Specs 7.1.2. Develop As Is and To Be documentation 7.1.3. Update Business Processes 7.1.3.1. Write new business processes 7.1.4. Complete User Training Manuals 7.2. Train users 7.2.1. Train IT Support Staff 7.2.1.1. Identify trainees 7.2.1.2. Identify trainers 7.2.1.3. Construct training schedule 7.2.1.4. Train users 7.2.2. Train employees 7.2.2.1. Identify trainees 7.2.2.2. Identify trainers 7.2.2.3. Construct training schedule 7.2.3. Train employees Discontinue Manual system 8.1. Verify New System 8.1.1. Obtain user acceptance of production system 8.1.2. Log issues 8.2. Monitor New system 8.2.1. Verify performance 8.2.2. Verify functionality 8.3. Project Wrap-up 8.3.1. Obtain Final Project Signoff 8.3.2. Document and Review Lessons Learned 8.3.3. Shut down the manual system
7.
8.
CE00348-3-PM
63
14.3 GANTT Chart
CE00348-3-PM
64
CE00348-3-PM
65
CE00348-3-PM
66
CE00348-3-PM
67
CE00348-3-PM
68
15. Reference
A Guide to the Project Management Body of Knowledge (PMBOK Guide), 3rd Edition, Project Management Institute, 2004. Bob Hughes, Mike Cotterell, (2009), SOFTWARE PROJECT MANAGEMENT, Publisher: McGraw-Hill Education; 5th Revised edition edition Charles A. Toth, 2006, A Bottoms-Up Approach To Cost Estimation Using Parametric Inputs, published by Ohio University David Ulrich (2008), Ulrichs HR Roles Model. [online] Available: http://hrmadvice.com/hrmadvice/hr-role/ulrichs-hr-roles-model.html [Last accessed 24th Jul 2012] David Hoyle (2007), Quality Management Essentials, 2nd ed. US: Paperback, Published by Butterworth-Heinemann, pg23 G J Rankins CPPD, (2009), Comparing PMBoK and PRINCE2 in 2009, OGC Conference, 14 September 2009, Brisbane, Queensland, Australia. Hughes, R. T. (1996), 'Expert judgment as an estimating method.' Information and Software Technology Jason Charvat, (2003), Project Management Methodologies: Selecting, Implementing, and Supporting Methodologies and Processes for Projects, published by Wiley; ISBN-10: 0471221783 Kathy Schwalbe, (2010), Managing Information Technology Projects, 6th Edition, Canada. PMI, 2004. A Guide to the Project Management Body of Knowledge (PMBOK Guide). 3rd ed. Pennsylvania, USA.: Project Management Institute Inc. O'Brien, Michael (October 8, 2009). "HR's Take on the Office". Human Resource Executive Online. [Last Accessed 24 July 2012] PMBOK Guide and Standards [Online], URL: http://www.pmi.org/PMBOK-Guide-andStandards.aspx [Accessed on: 02 July 2012] Meredith, J.R. and Mantel, S.J., (1995) Project Management a Managerial Approach, John Wiley & Son. Northrop Grumman Corporation, 2007, Communications Management Plan, Interoperability Montana
CE00348-3-PM
69
Peter Whitelaw, 2005, A Comparison Of Prince2 Against Pmbok, [online] http://www.bligoo.com/media/users/1/50369/files/4363/A%20comparison%20of%20Prince% 202%20vs%20PMBOK.pdf [Last accessed 24th Jul 2012]
Project Management Institute (Author), A Guide to the Project Management Body of Knowledge: PMBOK Guide, Project Management Inst; 4 Cdr edition (December 31, 2008), ISBN-10: 1933890746 Pmi Standards Committee (Author), PMI Standards Committee (Author), A Guide to the Project Management Body of Knowledge, Project Management Inst; illustrated edition edition (September 1996), ISBN-10: 1880410133 The Project Management Body of Knowledge (PMBOK) by Duncan Haughey, PMP, 2010, Project Smart R. Ashley Rawlins (2008). Total Quality Management. London: AuthorHouse. pg34. Rush, C., Roy, R. (2001). Expert judgement in cost estimating: Modelling the reasoning process. Concurrent Engineering: Research and Applications (CERA) Journal, 9(4) December 2001 David Hoyle (2007). Quality Management Essentials. 2nd ed. US: Paperback. pg23. Martin Murray. (2011). Total Quality Management. Available: http://logistics.about.com/od/qualityinthesupplychain/a/TQM.htm. Last accessed 18th July 2012 Suketu Nagrecha, (2002), An introduction to Earned Value Analysis, published by PMI Great Lakes Chapter, Yasmeen Begum (2009), Evolution of Human Resource Management, [online] Available: http://www.articlesbase.com/training-articles/evolution-of-human-resourcemanagement-1294285.html, [Last accessed 28th July 2012]
CE00348-3-PM
70

TMMPM In-Course Project

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

TMMPM In-Course Project

Enviado por

Direitos autorais:

Formatos disponíveis

Project Management For Total Materials Management and Planning Project Elham Sarikhani John Wilson Mahshid Sajedi

Staffordshire University/ Level 3

Asia Pacific Institute of Information Technology

Staffordshire University/ Level 3

Asia Pacific Institute of Information Technology

Staffordshire University/ Level 3

Asia Pacific Institute of Information Technology

Staffordshire University/ Level 3

Asia Pacific Institute of Information Technology

Staffordshire University/ Level 3

1.2 Current Developed System Failure Factors

1.3 Project Recovery

Asia Pacific Institute of Information Technology

Staffordshire University/ Level 3

2. Project Management Methodology

Components Integration Management

managements. Scope, and Cost

covered to have quality control in Configuration Management in Prince2. production.

Asia Pacific Institute of Information Technology

Table 2 PMBOK vs. PRINCE2 source: (Wideman, 2002)

Asia Pacific Institute of Information Technology

Staffordshire University/ Level 3

Asia Pacific Institute of Information Technology

Staffordshire University/ Level 3

Asia Pacific Institute of Information Technology

Staffordshire University/ Level 3

5. Grouping Reported Issues

Table 3 Grouping Reported Issues

Asia Pacific Institute of Information Technology

Staffordshire University/ Level 3

6. Project Scope Management

6.2 Problem Description

Asia Pacific Institute of Information Technology

Staffordshire University/ Level 3

6.3 Remedy Solution

Output Project scope management plan,

Work Breakdown Structure, WBS dictionary, scope baseline

Asia Pacific Institute of Information Technology

Staffordshire University/ Level 3

Techniques Product Analysis

Asia Pacific Institute of Information Technology

Staffordshire University/ Level 3

Component Project objectives

Asia Pacific Institute of Information Technology

Staffordshire University/ Level 3

7. Project Risk Management

7.2 Problem Description

7.3 Remedy Solution

Asia Pacific Institute of Information Technology

Staffordshire University/ Level 3

Risk Monitoring and Control

Staffordshire University/ Level 3

Competitors Cash Flow

Figure 3 Risk Breakdown Structure

Asia Pacific Institute of Information Technology

Staffordshire University/ Level 3

Category Cash Flow Estimates Hardware Software Executive support

Response Strategy Avoidance Avoidance Avoidance Avoidance Mitigation

Risk Owner PM PM PM SDM PM

Efficiency of the system is lower than client expectation

Software Network User Support Suppliers

Mitigation Mitigation Avoidance Avoidance

Asia Pacific Institute of Information Technology