An Analysis of the Case Study Revealed Absence of Basic Project Management Practices - Assignment Example

Project Analysis Problems An in-depth analysis of the case study revealed absence of basic project management practices that should have been done toachieve successful project completion. These are discussed below: First, the project scope was not clear as to what the software should look like. Its basic functionality requirements were not clear to Vendor Company (developer). Also it failed to translate expectations of the customer into meaningful requirements. Thus at the final QA evaluation, the functionality of the system was not at all that was demanded by the customer. The schedules were fast moving as timelines were not realistic. Vendor Company, developer of software, failed to identify the milestones and determine actual timelines that should have been agreed upon. Also it seemed that if a timeline was missed no significant effort was made to make up for the lost time. This was the reason that unreliable performances were seen at major milestones and it seemed that the developer of the software was running to meet the deadlines. There were changes to middle management during the project execution. However, it did affect the project as the management change would have also incorporated some changes in the project scope and functionality of the software. Another problem seen was low morale of the team. Unable to meet schedules and unrealistic performance at the major milestones adversely affected the team morale. Even when the memo was distributed to describing state of affairs and deadline to meet the project end date, still two weeks were lost in limbo. It seemed that the people working on the project accepted that it was not possible to meet the project completion date given the present state of affairs, that why a determined effort was found missing. The team appeared to be unsure of what needs to be done (Haynes 2009). As the project did not meet its deadlines and software functionality failed to meet customer requirements and expectations, strained relationships developed among the two major stakeholders. Conflict management techniques were the need of hour for effective damage control (Mulcahy 2009). Contract management aspect of the project was not effectively handled. This project was contracted to an outside company. It was important to determine the project assumption and constraints, expectations and requirements and project scope, and all this should have been reflected in to the project plan. Effective Project Management According to Project Management Institute (2008), project should have been broken down into phases and project life cycle determined. The stakeholders should have been identified and their need, wants, requirements and expectations determined, final objectives of the project clarified, requirements and functionality of the software finalized. All this was to be made part of the project charter duly approved by the customer company outsourcing the project. It was also vital to make this information part of the contract during outsourcing so that the vendor exactly knows what he has to do. Next was to make a realistic and effective project management plan. Once the project scope and charter have been finalized, it was important to determine team and create work break down structure and entire activity list of the project to make a network diagram. Then the estimates of resources, time and cost should have been determined and critical path evaluated (Mulcahy 2009). This information should have been used to determine the project schedule and budget. It was critical that same is agreed upon both by the customer and the vendor organizations (Taylor 2008)). Roles and responsibilities of the team and the communication requirements of the stakeholders needed clear identification. Risk identification, qualitative and quantitative risk analysis and response planning processes must be conducted during the planning stage of the project (Barkley 2004). If any of the middle management were to be changed during the project execution, it is critical figured out at this stage and it impact of the project should have been calculated. Although a mutually agreed upon project scope should have guarded against the scope creep. Also procurements if any were to be made, this also required identification and planning. During the project, it was vital to develop an effective team (Dyer 1995). For this team building and morale boosting tools and techniques seemed missing in the project. The team building efforts help to keep team focused on project objective and putting their utmost efforts towards successful project completion. Recognition and reward system would have augmented this effort. A better communication plan and effective team would not have allowed to waste two weeks at the critical project end stage because every would have been on the same frequency knowing his role. Mulcahy (2009) is of the view that another important function is to determine the variations in the project time and cost, and identify the root cause and solutions to meet the deficiency. These solutions should have been implemented through an integrated control system, a proper approval system associated with authority level. Identifying the project milestones and meeting these during the project could help in determining the variations in project factors affecting timely completion of the project. Shortcomings of project manager Following are few shortcoming of the project manager that were identified: Not identifying the stakeholders and not attempting to obtain finalized requirements. Not having a reward system Not focusing on quality Not having a control system Not having management plans Not measuring against the project management plan, or even creating metrics Not spending time finding and eliminating root causes of problems or deviations Not implementing corrective action to keep the project in line with the project management plan Not reevaluating the effectiveness of the project management plan Not reevaluating the accuracy or completeness of schedule, cost, scope Not realizing the project manager has some human resource responsibilities to the project team, such as project job descriptions and adding letters of recommendation to team members human resource files Not defining roles and responsibilities of the team members in accordance with work activities. Above were few shortcomings of the project manager and avoiding these pitfall could have brought project to a successful completion. Recommendations for project manager Based on the outcomes of the earlier efforts, project manager needs to be vigilant in following areas. First and foremost, project manager is not always a “Yes Man”, he can say “No” and should say when it is necessary (Mulcahy 2009). Considering the project scope and the remaining left time period of 12 days, project manager would have to make a comprehensive project management plan. He should present the management with all available option with the most practical one and must seek approval before proceeding. By that time, he should have re-evaluated project scope and software requirements, and present shortcomings. He should also evaluate schedule compression options like crashing, fast tracking and re-estimating. Crashing is making cost and schedule tradeoffs to determine how to obtain the greatest amount of schedule compression for the least incremental cost while maintaining project scope. (If time must change, what option will cause the least impact on cost?) Crashing, by definition, almost always results in increased costs (Project Management Institute 2008). Fast tracking is doing critical path activities in parallel that were originally planned in series. Fast tracking often results in rework, usually increases risk and requires more attention to communications (Mulcahy 2009). Re-estimating is making new estimations as to how achieve a compromise between cost, quality and scope of project to achieve timely completion (Haynes 2009). It is important for the project manager to study the business case and determine the cost –benefit, break even, payback and IRR if still the project is to be undertaken and convince the management if the option is not viable (Graves et al. 2003). He must determine the project cost, schedule, resource requirements and evaluate the critical path considering all activities to be undertaken during the project execution. A project managers job is to focus on preventing problems, not to deal with them. He should come up with a project management plan and must prepare a line of action to tackle with problems he identifies that would be coming. According to Mulcahy (2009), a project manager must believe that The project management plan is approved by all parties, is realistic and everyone believes it can be achieved. The project is managed to the project management plan. A project management plan is not a bar chart, nor is a WBS created in a bar chart or a list in a bar chart. If at all possible, project manager must identify all the work and all the stakeholders before the project begins. Stakeholders are involved in the project and may help identify and manage risks. They are involved in team building and their needs are taken into account while planning the project and in the communications management plan. A change in scope must be evaluated for impact to time, cost, quality, and risk and customer satisfaction. Project manager must have enough data about the project to do this analysis. To meet the quality objectives, project manager should always follow the plan-do-check-act cycle stressed in quality management. The project manager must put in place a plan for continually improving processes and must make sure the authorized approaches and processes are followed. The project manager has some human resource responsibilities. He needs to understand that people must be compensated for their work; therefore, he must create a reward system during the planning. Project manager should spend time documenting who should do what. All roles and responsibilities on the project must be clearly assigned and closely linked to the project scope statement. Quality should be considered whenever there is a change to time, scope and cost, and quality should be checked before an activity or work package is completed. Project Manager needs to identify all possible risks to the project and must conduct qualitative and quantitative risk analysis and response planning. Project Risks Following were a few risks that were associated with the project. Project charter was not formulated. Project charter should have been formed and duly approved by the project sponsor (Barkley 2004). Project scope statement was neither determined nor agreed upon by all the stakeholders. A project scope state would have helped in determining the project objectives. All the stakeholders were not identified and their requirements and expectations were neither determined nor embedded in project work. The stakeholder expectation should have been included in the project management and agreed upon to prevent against project scope creep in the next project phases (Antonioni 2009). There was no project management plan. It is important to have a project plan because all activities are worked upon in accordance with the project plan (Mulcahy 2009). There were no efforts for project team development and their management. Roles and responsibilities of team members were not clearly defined. No communication plan was developed and it was not known as to what information is required by whom. A communication plan should have been developed for this purpose. Project life cycle was not identified. This has already been discussed in last section. Not all the work and activities required for project completion were determined and agreed upon. Network diagram and critical path was not established. Milestones were not determined and were not placed against the project timeline for effective monitoring. There was no effective quality control and quality assurance system prevailing in the project, and the result was unreliable software functioning. According to Project Management Institute (2008), effective project risk management includes Risk Management Planning – deciding how to approach, plan, and execute the risk management activities for a project. Risk Identification – determining which risks might affect the project and documenting their characteristics. Qualitative Risk Analysis – prioritizing risks for subsequent further analysis or action by assessing and combining their probability of occurrence and impact. Quantitative Risk Analysis – numerically analyzing the effect on overall project objectives of identified risks. Risk Response Planning – developing options and actions to enhance opportunities, and to reduce threats to project objectives. Risk Monitoring and Control – tracking identified risks, monitoring residual risks, identifying new risks, executing risk response plans, and evaluating their effectiveness throughout the project life cycle. Recommendations Following are few recommendation for future projects of this type: Project life cycle Project managers or the organization can divide projects into phases to provide better management control with appropriate links to the ongoing operations of the performing organization. Collectively, these phases are known as the project life cycle. Many organizations identify a specific set of life cycles for use on all of their projects (Knutson and Bitz 1999). The project life cycle defines the phases that connect the beginning of a project to its end. For example, when an organization identifies an opportunity to which it would like to respond, it will often authorize a feasibility study to decide whether it should undertake the project. The project life cycle definition can help the project manager clarify whether to treat the feasibility study as the first project phase or as a separate, stand-alone project. Where the outcome of such a preliminary effort is not clearly identifiable, it is best to treat such efforts as a separate project (Mulcahy 2009). The transition from one phase to another within a project’s life cycle generally involves, and is usually defined by, some form of technical transfer or handoff. Deliverables from one phase are usually reviewed for completeness and accuracy and approved before work starts on the next phase. However, it is not uncommon for a phase to begin prior to the approval of the previous phase’s deliverables, when the risks involved are deemed acceptable. This practice of overlapping phases, normally done in sequence, is an example of the application of the schedule compression technique called fast tracking. Nokes and Kelly (2007) are of the view that there is no single best way to define an ideal project life cycle. Some organizations have established policies that standardize all projects with a single life cycle, while others allow the project management team to choose the most appropriate life cycle for the team’s project. Further, industry common practices will often lead to the use of a preferred life cycle within that industry. According to Project Management Institute (2008), project life cycles generally define: What technical work to do in each phase (for example, in which phase should the software development work be performed?) When the deliverables are to be generated in each phase and how each deliverable is reviewed, verified, and validated Who is involved in each phase (for example, concurrent engineering requires that the implementers be involved with requirements and design) How to control and approve each phase. Project life cycle descriptions can be very general or very detailed. Highly detailed descriptions of life cycles can include forms, charts, and checklists to provide structure and control. Most project life cycles share a number of common characteristics: Phases are generally sequential and are usually defined by some form of technical information transfer or technical component handoff. Cost and staffing levels are low at the start, peak during the intermediate phases, and drop rapidly as the project draws to a conclusion. The level of uncertainty is highest and, hence, risk of failing to achieve the objectives is greatest at the start of the project. The certainty of completion generally gets progressively better as the project continues. The ability of the stakeholders to influence the final characteristics of the project’s product and the final cost of the project is highest at the start, and gets progressively lower as the project continues. A major contributor to this phenomenon is that the cost of changes and correcting errors generally increases as the project continues. Although many project life cycles have similar phase names with similar deliverables, few life cycles are identical. Some can have four or five phases, but others may have nine or more. Single application areas are known to have significant variations. One organization’s software development life cycle can have a single design phase, while another can have separate phases for architectural and detailed design. Subprojects can also have distinct project life cycles. For example, a typical software development project may have life cycle phases including requirements analysis, high-level design, detailed design, coding, testing, installation, conversion and turnover to operations Stakeholder management A stakeholder is someone whose interests may be positively or negatively impacted by the project. Key stakeholders include: the project manager, customer, performing organization, project team, project management team, sponsor, and the project management office. They may also include those who may exert influence over the project, but would not otherwise be considered stakeholders. It is critical to identify stakeholders needs, wants and expectations are turned into requirements. A project manager must remember to do following for effective stakeholder management (Antonioni 2009). Mulcahy (2009) stresses to identify all of stakeholders. Any stakeholders who are missed will likely be found later. When they are uncovered, they will make changes and could cause delays. Changes made later in the project are much more costly and harder to integrate than those made earlier. Identifying all the stakeholders helps create a better organized project that meets all the stakeholders interests. Determine all of their requirements. This is neither easy nor fast, but the project manager must make every effort to obtain all the requirements before the work begins. Determine their expectations. These are things the stakeholders expect to happen to them, their department and the company as a whole. They tend to be much more ambiguous than stated requirements, or may be undefined requirements. They may be intentionally or unintentionally hidden. Communicate with them. Stakeholders communications requirements must be determined early. Their information needs are analyzed and considered throughout the project. They are included in project presentations and receive project information including progress reports, updates and changes to the project management plan. Manage their influence in relation to the requirements to ensure a successful project. Stakeholders have greater influence over the requirements early in the project, but changes to the project requirements can have negative overall consequences to the project throughout the projects life. Maintaining Issue Log. It is important to document and record all the issues, action taken and their results in an issue log for future reference. An issue log or action-item log is a tool that can be used to document and monitor the resolution of issues. Issues do not usually rise to the importance of becoming a project or activity, but are usually addressed in order to maintain good, constructive working relationships among various stakeholders, including team members. Effective project teams Team building is forming the project team into a cohesive group working for the best interest of the project, in order to enhance project performance (Dyer 1995). A project manager must know that It is the job of the project manager to guide, manage and improve the interaction of team members. The project manager should improve the trust and cohesiveness among the team. Project managers should incorporate team building activities into all project activities. Team building requires a concerted effort and continued attention throughout the life of the project. The WBS creation is a team building tool. Team building should start early in the life of the project. Team building activities can include: Milestone parties Holiday and birthday celebrations Outside of work trips Creating the work breakdown structure Planning the project by getting everyone involved in some way Kerzner (2009) is of the view that any training needed by the team members in order to perform on the project or to enhance their performance should be paid for by the project. The project manager should look for such opportunities not only to help team members, but also to decrease overall project cost and schedule by increasing project efficiencies. Performance is appraised and rewards and recognitions, planned in project plan, are to be given out. Team Performance Assessment Team performance assessment is done by the project manager to evaluate and enhance the effectiveness of the team as a whole. Think of team performance assessment as "team effectiveness." This may include an analysis of how much team members skills have improved, how well the team is performing, interacting and dealing with conflict, and the turnover rate. Another Example The Never Ending Scope Creep This case study was published on website of Expert Project Management in 2003 as is presented as it is without any omission or alteration. In 1999, the XY Department of the Federal Government reviewed its Year 2000 Date Turnover Computer Risks and found that its outdated computer systems for managing public clients needed replacing. A business case was prepared for funding the replacement while at the same time implementing some improvements. The total budget requested was $2.3 million. In view of a shortage of funds around at the time, government did not approve this amount. Only $1.5 million was authorized. However, the XY Department accepted this amount after they decided that they could maybe do the work for around the $1.5 million. Accordingly, a project was scoped and planned, with specific milestones for implementing the hardware and, subsequently the software, across 87 sites within its jurisdiction. A final completion date of 30th June 2001 was projected. The original business case had loosely identified some risks to the project that were also included in the project plan. A project steering committee was established, with the department chief (CEO) as the sponsor, and representation by influential managers with differing outcome needs to suit their particular work environment. The project commenced in July 1999. In view of the shortfall on its original budget request, the committee decided not to employ a project manager. Instead it assigned this responsibility to its Finance Manager, who would undertake the work along with his normal duties. A Company, called "Good Programs" was contracted to supply the software and assist in the implementation. This company recognized the marketing opportunities of this project, as the XY Department was its biggest client in the region. As a result, they offered, free of charge, many more features that were not in the original scope, provided the department allowed them to be, in essence a research and development (R&D) site. This would assist Good Programs to more readily sell their products elsewhere around the world, while providing the XY Department with additional functionality and benefits. Initially, the steering committee met regularly, but as new versions of the resulting software were being implemented regularly, meetings became less frequent and Good Programs were left to do more and more of the day to day management of the new version implementations. These new versions were developed after consultation with the various individual managers to accommodate requested new features with little consultation amongst all of the managers. All the XY Department and steering committee had to do was to identify problems with the software and to make the system testers available for new versions. However, the effect was an unanticipated overhead for the department. Sometime after the original project was scoped and commenced, both the original CEO and finance manager had been moved out of the department and new officers have been appointed. At this time, the new CEO has been advised that about $185,000 more is needed for the project, which is not in his current budget. The original project has not been signed off, indeed, it is evident that it has not been completed. The new CEO of the department is not sure of the original scope of the project, what aspects have been implemented, nor what has been spent for which parts. There do not seem to be any reliable reports available as to original scope, scope changes, schedule or budget. The CEO is concerned that the project has become more of a career than a project, with version 16.5 of the client management system now being tested with yet more features. In addition, there are some past software problems that are still outstanding. Nevertheless, Good Systems have promised that problems will be fixed in the next version and they formed a new project team to address all the issues with in stipulated project time. References Project Management Institute. (2008) A Guide to Project Management Body of Knowledge, 4th ed. Pennsylvania : PMI Publishers. Dyer, W. (1995) Team Building, Boston: Addison-Wesley. Kerzner, H. (2009) Project Management: A Systems Approach to Planning, Scheduling, and Controlling., New Jersey: John Wiley & Sons. Mulcahy, R. (2009) PMP Exam Prep, 5th ed. New York: RMC Publications. Haynes, M. (2009) Project Management : Practical Tools for Success, California: Crisp Publications Inc.. Knutson, J. and Bitz, I. (1999) Project Management : How to Plan and Manage Successful Projects, New York: AMACOM Publications. Nokes, S. and Kelly, S. (2007) The Definitive Guide to Project Management, 2nd ed. New Delhi: Dorling Kindersely. Barkley, B. (2004) Project Risk Management, New York: Mc-Graw Hill Publishers. Taylor, J. (2008) Project Scheduling and Cost Control: Planning, Monitoring and Controlling, Florida: Ross Publication. Antonioni, D. (2009) Crafting The Art of Stakeholder Management, Industrial Management, 51(1). Graves, S. et al. (2003) Models & Methods For Project Selection, Massachusetts: Kluwer Academic Publications. Expert Project Management (2003) Case Study #1: The Case of the Never Ending Scope Creep, [online] Available at: http://www.maxwideman.com/papers/casestudies/case1.htm [Accessed: 5th Dec 2011]. Read More