This exchange is similar to the current state of IT project planning. With ample bravado -- and myopia -- many project managers are tempted to jump from the germ of an idea to full execution of a project in the name of efficiency, creativity and, above all, customer service. As a result, true project planning -- which involves outlining the deliverables, team training and quality management, among other steps -- gets short shrift. IT project managers often operate on the principle that the execution can be accomplished on the fly.
No professional civil engineer, for example, would sign off on the construction of a building without first developing plans for the foundation, superstructure and heating systems (and no sane owner wants a structure built any other way). Engineering project managers rarely, if ever, complain that too much planning is getting in the way of project progress. But IT project managers and business-side executives alike often consider comprehensive planning a roadblock on the path to creativity. Their credo is, "We don't need no stinking plans."
So why do IT project managers and business-side executives approach projects differently? In my view, the problem is that project managers have become accustomed to a culture of constant project snafus, last-minute change requests and accompanying workarounds that they use as justification for failing to plan up front. But what many managers and executives partial to the no-need-to-plan approach fail to see is that the depth and the breadth of planning directly correlate with project complexity. The greater the complexity, the more detailed the project plan should be. If you have limited time and budget for planning, here are the most important areas where you should expend resources to ensure successful projects.
- Development and deployment. This includes the deliverables and tasks for the design, construction and implementation of the final product. Far too many project plans stop here. The end result: mayhem during deployment.
- Organizational change management. All projects cause some degree of change. And the greater the change, the greater the number of deliverables and tasks. Don't focus on what the new project will do but on how. New human-technology interfaces, processes and terminology are all areas that factor into change management efforts.
- Team education and training. All medium-to-high-complexity projects require the education of team members about the new technology and business processes. This activity is often sidestepped because of the added time and cost to the project.
- Customer training. This activity is often overlooked. One of the key reasons for "challenged" (i.e., deployed but underused) projects is the lack of timely and adequate customer training. Additionally, customer training should be done during the early planning phases rather than after implementation when the training blitz typically begins.
- Regulatory compliance. With the growing threat of security breaches and financial malfeasance, many projects require robust firewalls and compliance with the Sarbanes-Oxley Act, among other regulations.
- Exit strategy. In the event of failure, high-risk projects benefit from a plan B.
- Current system retirement. If the new product replaces a current system (such as hardware or software), have a retirement plan for the old system; otherwise customers may continue to use it, which can result in duplicate efforts and corrupt data.
The "We don't need no stinking plans" approach is akin to throwing the baby out with the bathwater and has contributed substantially to the high rate of challenged and failed projects.
Gopal K. Kapur is president of the Center for Project Management in San Ramon, Calif., and author of Project Management for Information, Technology, Business and Certification. Write to him at ProjectExpert@ciodecisions.com.
This was first published in December 2006