07/02/07 01:04 pm ET
A new report from the IT management consulting firm Forrester Research identifies the 10 most common mistakes in project development and how to avoid them. Forrester researchers point out that many of the mistakes are well known. Nevertheless, project developers keep making them, so it is always helpful to review them, Forrester advises.
The top 10 are:
1. Never committing to project success. When a project threatens a business unit, it has a low chance of succeeding. Users in a unit undergoing technological change are not helpful in identifying requirements and are vague about their work. Developers need to work extra hard in showing why the project is useful.
2. Freezing the schedule and budget before the project is understood. Executives tend to hold project developers to the initial, yet sketchy, budget and schedule timelines. Because developers don't understand much about the project at the beginning of the cycle, estimates are no more than guesses. Some developers fund a team to investigate the project's details to create a more informed budget and schedule.
3. Overscoping the solution. Forrester calls this using "a chainsaw to open an envelope." Sometimes a simple tweak or fix -- not a new system -- to an existing application is all that is needed to satisfy a requirement.
4. Circumventing the application development organization. Sometimes a business unit or agency office will hire a contractor to develop an application without informing the central IT office. Integration with the organization's systems can prove troublesome. The application development team must educate the organization's units that it should be informed to avoid technical problems.
5. Underestimating the complexity of the problem. Business users fail to provide the necessary detail for requirements so that the application development office can judge how complex the functionality of the system must be. To avoid this problem, the Program Management Office must deliver applications in stages to receive feedback on whether the system is meeting requirements. That way adjustments can be made earlier in the process, saving money and time.
6. Being stingy with subject-matter experts. When the line of business does not provide enough subject-matter experts -- those who intimately know the business and what a system needs to serve the business requirements -- projects go off track. Without a subject matter expert, application developers will tend to make their own decisions as to what needs to be done to keep the project on schedule. To make it work, a subject matter expert or experts must be freed up from their daily jobs to devote a large part of their day to the project.
7. Choosing the wrong project leadership. Mistakes include identifying two project heads without stating who has authority, and, two, creating a working committee that is too large. A project leadership team with 20 participants is "inertial," Forrester reported. "An informed few can proxy for the many, and only one of the few should clearly have final decision-making power," Forrester reports.
8. Distrusting the managers to whom tasks have been delegated. Another way to put it: avoid micromanaging. Do not use steering committees to delve into technical details, for example. That only alienates managers and takes valuable time away from making decisions that are needed to advance the project, Forrester concludes.
9. Jumping into the “D” of “R&D” without enough “R.” Schedule pressures, and an enthusiastic technical staff, tend to take away time for properly scoping out a project and learning exactly what is being asked. Build in investigative time into schedules, Forrester advises.
10. Suppressing bad news. Some organizational cultures view problems as embarrassing. That means the staff is reluctant to point out problems, even it means bigger problems will occur later in the project cycle. Discuss problems as they occur, Forrester recommends.
COMMENTS
Forrester provides a good listing, one that contains enough items to remind readers that project management requires initial, consistent, purpose-driven due diligence from project inception to initiation, planning, execuction, monitoring, control, and closure--through the entire life cycle on each and every project until termination or completion. Alternative or supplemental "Top 10" items could be as follows but not necessarily in the order presented:
*** Poor development of project initiation inputs cause "garbage in, garbage out" effect and the need to slow down in initiation to assure proper charter and preliminary scope development. Otherwise, planning will begin at a substandard level and cause multiple additonal problems.
*** Poor project selection, prioritization, and authorization decision making at the project portfolio management level puts limited project management resources to work on the wrong projects in the wrong order at the wrong time.
*** Plowing ahead on stovepiped projects that are logically related drives inefficiencies. An example would be an attempt at management of separetely handled modules for a large system, when instead the modules should be planned and otherwise handled within a program as a set of multiple integrated projects.
*** Ignoring project management's place as an equal to operations management in project heavy organizations. This relegates a key specialized management method and impairs general management's ability to support operations, achieve change in the operational environment. It also impedes progress toward strategic objective and goal attainment.
*** Viewing project management as simplistic when in fact "total project management" comprises standard project management, program management, and project portfolio management. Each of these three levels, especially program and portfolio management, tend to get ignored or treated with indifference in organizations with a low organizational project management maturity level.
*** Limiting formal project (and program and portfolio) management to a particular functional area such as IT. This causes project management proficiency skewing across an organization, for example through use and advancement of project management in IT while HR and Finance in particular, and other areas, lag.
*** Not understanding and not using methodical project, program, and portfolio management process tailoring leads to overuse of some facilitating processes and underuse or non use of mandatory core processes in projects and programs that vary by size, duration, cost, and dozens of other typical charateristics or traits.
*** Not doing project cost management (estimating, budgeting, and control) on projects involving only internal human resources. This prevents organizational management's ability to see and control and continue or kill projects based on staff cost. It also prevents a view of total project cost.
*** Not doing initial project risk planning and not reviewing project risks at all regular project status meetings ignores a key aspect of cost and schedule variance management planning and control.
*** Not making use of a properly developed project schedule as a transactional communication management tool is a basic mistake. All required activities are in such a schedule along with all expected milestones representing initial, intermediate, and final deliverables. When not used as a communiction tool, the schedule's visibility diminishes along with regular time, scope, and cost control.
Frank Cox, MS, PMP 06/26/09 10:16 am ET
Great write up!
I really enjoyed it. From my personal experience and after interviewing project managers I can say that managers often forget about leadership at all. They are often overloaded with routine operations like digging through emails and collecting updates, then manually updating project plans. That's why developing an innovative pm solution (wrike) we concentrated on this problem. Our aim was to make a pm's life easier. It would be great to get your feedback on the tool.
Daria 12/23/08 05:36 am ET
Excellent observations from Forrester. Another big problem, not mentioned, is accurate progress tracking. On that note, the Office of Management and Budget (OMB) has mandated the use of Earned Value Management (EVM) - a highly collaborative approach to progress measurement - as a method of tracking project performance to help agencies meet project goals. Project managers using best EVM practices can avoid a lot of project management pitfalls and improve agency results.
-- Jim Foreman, Vice President of Client Solutions, ESI International (www.esi-intl.com)
Jim Foreman 07/05/07 02:22 pm ET