How to identify a failing project 실패하는 프로젝트의 일치성을 확인하는 방법

How to identify a failing project by Jason Charvat in Project Management on November 15, 2002, 12:00 AM PST Has your project gone out of control—threatening to be both behind schedule and over budget? The warning signs were probably there from the beginning. Here's how to figure out what went wrong and what you can do to save a failing project. IT projects that spiral out of control need project managers with skill, experience, and resilience to get them back on track. You may develop a hunch that a project is starting to get out of control when you notice that stakeholders are not attending project meetings, developers are leaving the project, or the financial group is asking just too many questions about daily expenses/resource allocations. Your hunch may be on target when you consider that leading industry research groups such as Gartner, META, and the Standish Group International all point to a high percentage of IT projects failing. Your challenge as a project or development manager is to proactively identify projects that have gone bad and then decide whether to reengineer (i.e., retrofit) those problems. Bad projects, left untouched, could cause irreparable harm to any organization. This article highlights some of the key problems that may put your project at risk and provides some tips on how to correct them. Analyzing a failing project My experience includes work as a consultant, assessing why a major project had missed its sixth deadline in five months. I started by reviewing the project (i.e., project budget and expenses, the completeness of the project binder for specifications, plans, and e-mails, etc.) and then interviewed all stakeholders. The review revealed that the project was in fact running at a tremendous loss, had no change control procedure in place, and wasn’t staffed very well either. Worst of all, many key project members just couldn’t wait to tell me whose fault they thought it was. The executive team of the company couldn’t understand why the project was doing so poorly because previous updates from the project manager indicated otherwise. The project was extremely critical to the company’s survival, and we had no choice but to proceed with its deployment. But we decided to stop all project activities for a period of two weeks in order to replan, modify the design, improve the communication strategy, and then, finally, realign all the necessary resources. The project was then restarted and quickly showed signs of improvement. Identifying out-of-control projects While few project or development managers want to admit it, critical mistakes are made. Effective managers need to be able to identify where their projects/programs go out of control, especially considering that almost two-thirds of all IT projects fail, according to some estimates. The question that comes to mind is: Why do so many of the critical issues fail to show up on the project/development manager’s radar? Is it, perhaps, that he or she is unable to identify these problems? Some typical problems you may encounter on a project, together with possible solutions, are shown in Figure A. Figure A Symptom Solution Poor communications Develop a communications plan and inform all stakeholders · Establish frequent project meetings · Document roles & responsibilities Poor estimation & planning Use Analysts, SMEs and/or Cost Estimators to assist in estimating Minimal documentation Identify the minimum documentation needed on the project · Business Case / Project Brief · User Requirement Specification · Technical Specification(s) as needed · Deployment Plan · Project Schedule · Training schedule · Test Plan Poor project management Either replace the project manager with a stronger candidate or involve executive direction and leadership Poor executive buy-in Obtain immediate executive sponsorship through escalation Poor user requirements Document and approve user requirements and establish the necessary change controls to support any future changes Depending upon the unique aspects of a project, there could be a multitude of reasons for a project going out of control. Risk factors include the following: Sloppy requirements: Every project depends upon solid user requirements being firmly locked down prior to any work being undertaken. Failure to do so is a leading cause for project failure. Somehow, the trend is that many project teams think they can get started by rushing the requirements-gathering phase. These projects are then eagerly started with incomplete requirements. If you are developing a project using a standard waterfall methodology, any incomplete requirements will have both a negative cost and schedule impact on the project. On iterative development projects, user requirements are still of utmost importance, but can be negotiated ahead of any actual development. Schedule slippage: Many times, project schedules spiral out of control when dates and deliverables aren’t aggressively monitored and tracked on a daily basis. All too often, managers leave issues unresolved for days, which then results in schedule overruns. I recommend that that you check project schedules daily. Budget overrun: Projects that run over budget are sometimes more prone to being canceled because senior executives are concerned about cash going into and out of company coffers. If a project starts showing gradual cost overruns, the project is often still given a chance, but, as the losses mount and show no sign of recovery, canceling the project may be necessary. In reality, though, some projects are so critical to business survival that they can’t be stopped. Therefore, the cost overruns are simply absorbed or skillfully transferred elsewhere. This means that project managers must manage their actual budgets against the planned budget and keep their stakeholders aware of any deviation. Scope creep: When clients insist on ever-increasing changes to the product being developed, scope creep can jeopardize the project. I don’t know of too many project managers who can handle too many changes all at once. An even more difficult situation for a project manager surfaces when new changes are introduced after the project has been launched. This usually drives up the cost, resource requirements, deliverables, and completion time. Scope creep needs to be managed and the project manager needs to have a change control process in place to assess the impact and cost of the change and, possibly, negotiate the change for a future release. Poor planning and estimation: Those projects that are poorly estimated and planned tend to fail both in cost and schedule, which eventually causes the overall project to fail. Managers tend to start projects without relying on proper analysis, and sizing, and fail to consult subject matter experts or cost estimators to validate how much project work packages will cost. Poor documentation: Maintaining inadequate project documentation is cause for concern and should raise the red flag. Lessons learned from many failed projects reveal that there was too little documentation to adequately describe the project in its broader terms, and serve as a clear communication channel. New technology: Projects that require integrating new tools and deploying new vendor applications/devices are always far more difficult, because usually, only the vendor engineers clearly understand the limitations and functionality of the products. This results in delays in project schedule and could require weeks or months before the products are stable enough to be deployed. If a project is undertaken using new technology, managers should be aware of the associated risks and plan their schedules accordingly. Poor communications: One of the biggest reasons why any project goes bad is due to a lack of communication. I have seen many projects fail simply because no one understands what to do and receives no communication as to current progress; this, inevitably, results in project failure. Poor decision-making: Decision that aren't made at all and decisions that are delayed due to second-guessing are both risk factors. Additionally, some decisions are so turned out-of-context as responsibility for them is passed down the line that they end up being made based on faulty information. This doesn’t bode too well for any critical project. Poor project management: The person managing the project may not have the skills or experience to pull it off. Yes, any project can be stuck with a lame duck manager. In such cases, it may be necessary to stop the project, replace the project manager, make the necessary adjustments, and start again. The departing manager should be given the option to provide his/her version of the story, though, before moving on. Poor testing: A big culprit on any project is having either too little testing or, in many cases—if a test team is involved—testing too late in the process. Both testing and quality assurance need to be built into the project from the day the project is launched. So what do you do? Many companies initiating projects often don’t anticipate any tsunami-like problems hitting them. They expect project managers to have done all the fancy footwork, such as planning and estimating the project correctly, and then to drive the project home exactly as planned. But when serious problems do surface and put the project at risk, then more desperate measures are needed, including stopping or reengineering the project. At this stage, you are probably at your wits' end and may need help. When problems spiral out of control and projects start going bad, managers sometimes ignore the root causes and simply try and force their projects along the designated schedule, without regard to the future problems on the horizon (e.g., schedule slippage, budget overrun, resource clashes, cancellation, etc). The project then basically goes into a reactive mode, and nothing is ever the same again. For example, a critical project that has not addressed user or support training and is near the delivery stage is looking for serious trouble. This problem—caused by poor planning—won't go away and would likely require some reengineering to get the project back on track. If this project is a fixed-price project and performed by an external contractor, it is probable that the contractor will absorb the loss as well as the slippage in the schedule. If this were an in-house project, company executives would be faced with stopping the project, scheduling training, having the users trained, and then starting the last piece of the deployment. Steps toward finding the fix For project managers working against time (i.e., competitive industries), it may be useful to try to get the project back on track by taking the following steps: Read between the lines: Once you start getting wind of problems such as schedule, quality, cost, resource conflicts or late status reports, then I’d recommend a one-on-one review with the applicable project manager as soon as possible to determine the project’s true status. Recognize what went wrong: Try and assess what the reasons were for the project failing in the first place. It’s no use simply blaming people. If the failure was due to bad estimation or planning, then efforts need to be put into place to correct any future projects following the same path. Determine what to do: Should you cancel a bad project or try and bring it back on track? Organizations faced with bad projects should first try and salvage their poor performers rather than canceling them. Educate your project staff: Training and education really go a long way to correcting bad project practices. Across the enterprise, project and development managers have to be able to recognize the symptoms and warning signs of IT projects running aground. Those tools currently in place to correct problems (e.g., issue spreadsheets and monthly status reports) are just not good enough. Left untouched, it is no wonder we have such a dismal project success rate. WHITE PAPERS, WEBCASTS, AND DOWNLOADS Sales Force Automation Pack Tools & Templates from TechRepublic Premium DOWNLOAD NOW Non-Disclosure Agreement Template Tools & Templates from TechRepublic Premium DOWNLOAD NOW Quick Reference: Microsoft Excel Tools & Templates from TechRepublic Premium DOWNLOAD NOW IT Consultant Conduct Policy Tools & Templates from TechRepublic Premium DOWNLOAD NOW Job description: IT project manager Tools & Templates from TechRepublic Premium DOWNLOAD NOW EDITOR'S PICKS Python is eating the world: How one developer's side project became the hottest programming language on the planet How iRobot used data science, cloud, and DevOps to design its next-gen smart home robots Beyond the PC: Lenovo's ambitious plan for the future of computing Straight up: How the Kentucky bourbon industry is going high tech Inside the Raspberry Pi: The story of the $35 computer that changed the world Smart farming: How IoT, robotics, and AI are tackling one of the biggest problems of the century RELATED TOPICS PROJECT MANAGEMENT CXO SOFTWARETECH & WORK SMART PERSONS GUIDESPROJECT MANAGEMENT ON ZDNET Promoted Links Recommended 그토록 원하던 뱃살이 사라져...! 하루 2번 '이것'과 함께했을 뿐인데!올컷다이어트