Giga Position
Organizations continue to look for the key to unlocking the mystery of project management (PM) best practices, but the steps that go into successful project management are not mysterious at all — they are standard procedures that, if executed, will improve a project’s chances of success. The key word here is “if.” Projects fail because of poor planning and fuzzy requirements that cause a chain reaction of poor productivity. Regardless of size, good projects benefit from careful planning and active management. Follow the 20/80 theory: Increase your planning process by 20 percent, and you will reap 80 percent growth in productivity.
Giga expects to see an annual 15 percent per year increase in formal project management practices during the next five years. Companies formalizing these practices will have to develop and actively use management procedures, including planning and communication, to facilitate project delivery.
Recommendations
Build a best-practice library of methods that have worked in previous projects. Keep it modular, so that procedures can be tailored for a specific project based on size, complexity, team structure, etc. The library is a living repository that grows with each completed project. Requirements management tools are excellent repositories for artifact information that can be reused for efficiency, as are project management tools that store completed project plans that can be reproduced as templates. As projects are completed, perform a postmortem to update or change procedures for continual improvement.
For organizations that do not have accessible historical project data and want to purchase developed methodology, consider a training program with certified training consultants that offers not only core methodology training, but also key areas, such as cost management, assessments and requirements management. Another alternative is to contract a specific project with a consulting organization that can deliver proven project plans and will transfer knowledge and practices.
Refer to standard industry reference material as a guide for building internal practices; the Project Management Institute’s (PMI) Body of Knowledge (PMBOK) provides detailed information about core professional project management procedures. ISO 9000 and the Capability Maturity Model (CMM) are also excellent sources for best practice information. While each of these standards may be too involved for your organization’s requirements, there may be individual procedures you can use that will improve weak areas in current practices.
Proof/Notes
We Don’t Have the Time to Do It Right, but We Have the Time to Do It Over
Despite the claim that project management is widely accepted as common practice, the reality is that less than half of the companies claiming to have integrated project management practices have standard procedures extending beyond strategic projects (see IdeaByte, Enterprise Project Management Tools: Is Your Company Ready? Margo Visitacion). Performance is ad hoc and changes with each new project. Without a standard foundation for execution, projects fall down when there are no standard procedures. Failure to gather and maintain adequate requirements causes project teams to have to rearrange delivery dates and to miss deadlines. Organizational pressures, such as lean resource availability, cause continual resource constraints, forcing project managers to scramble to find adequate coverage. When the pressure to deliver becomes too great, common sense often goes out the window, and then crucial steps, like testing, are skipped. The end result is shoddy, and the rework required to repair the damage is far more expensive than if it were caught in the planning stages.
All projects come under fire, but in an uncertain economy, increased pressures to derive optimal value emphasize the need to ably deliver projects. Reduced budgets and leaner staff do not equal reduced expectations; companies with smaller staffs and/or increased reliance on outsourcing are realizing that strong process is the key to better application development and avoiding expensive rework. Even in accelerated life cycles, planning and management best practices can be exercised. In traditional projects, planning was an exhaustive process; in accelerated cycles, successful planning concentrates on drawing boundaries to create a prioritized set of deliverables that are released in iterative phases. Process is not about reinventing the wheel, but finding what has worked in the past and applying it to the present, using strong communication to deliver and manage these processes and paring away anything that diverts the team from project goals. The ultimate challenge for project management is to find a repeatable process and communicate it clearly so that multiple levels within an organization accept and support the benefits.
Project Management Best Practices
The best practices of project management have been written about in dozens of formats. The PMBOK breaks it into 37 key process areas; most projects are finished before the project manager actively understands what those areas are. From an educational standpoint, the PMBOK provides a manager with an excellent explanation of why each area is important; unfortunately, current life cycles do not actively support every detail mentioned in PMBOK. Flexibility is vital here. In order to plan and execute effectively, break it down into small repeatable phases that can be arranged to best suit the project’s goals. For example, portions requirements management will be practiced throughout the life of the project in status meetings and in audit processes. Take the information gathered as part of requirements management (RM) as a guide for measurement to keep project scope in alignment. There are many things you can do to manage projects;
however, the following are practices that you must perform in order to execute a successful project:
Scope:
§ Know if it “cuts the mustard”: Before undertaking any project, evidence must exist to support its value. Perform a feasibility study to gauge market potential, enterprise risk/benefit and technological impact before any activities are started (see IdeaByte, What to Include in a Feasibility Study, Margo Visitacion).
§ Follow a structured initiation process: Gaining executive understanding and commitment before undertaking a project, especially one that carries some risk for IT, prevents political jockeying over priorities and resource commitment. Make sure that the project has a designated business champion, and gather the necessary business and technological criteria to justify the project to continue adequate executive support during the life cycle.
Planning:
§ Plan: Comprehensive planning is critical, even with short development cycles. Make project goals attainable by prioritizing deliverables to keep a team tightly focused on specific issues. From there, involve the team, stakeholders and sponsors in closely managed sessions to discuss each objective and clearly explain risks and benefits to understand exposures and the dangers to the project. Doing this promotes a unified front, because everyone understands how the project is affected by unnecessary changes, especially if it is understood that more features will follow shortly (see IdeaByte, Effective Risk Measurement in IT Projects, Jon Erickson).
§ Maintain realism in planning: Determine short-term “must haves” (e.g., one to three months) and long-term goals (e.g., one to three years). In order to keep to delivery dates, it is often necessary to deliver a streamlined application or site with enhancements coming in regular scheduled intervals. Open communication at this point is critical to maintain expectations. Meet weekly with stakeholders to keep scope creep to a minimum.
§ Assess requirements: Perform stakeholder interviews to ascertain the business and usability objectives for the project. Hold collective review sessions and prototyping whenever possible to keep the project team focused on the correct path and manage end-user expectations. Automate the requirements management process whenever possible to provide a central location for audit trails and status management.
§ Don’t overload milestones: Keep the milestones actionable, and keep them close together (ideally, no more than three weeks apart); however, in a project of less than three months in duration, the spacing can drop to 1½ weeks. This is critical if you are opting for short-term deliverables within a compressed life cycle. Closely spaced milestones provide opportunity for faster recovery if the project starts to stray.
§ Publicize your plans: Distribute regular and relevant status information in the most accessible way possible, for example, e-mail, intranet project pages or an enterprise project management tool. The more people who are intimately familiar with project requirements and action plans, the less cause there is for a misstep. Broad access increases the chances of catching a potential problem that a project manager may have missed.
§ Delegate: A project manager cannot, and should not, do it all. Use the team approach whenever possible for planning and execution, guided by the project lead. For example, the system architect and senior programmer manage the architectural and system design phases of the project and report to the project manager, who focuses on administrative and coordination activities.
§ Manage vendors: This has two meanings. During the planning phase, if standard tools for communication and execution are not in place, it is critical for the team to implement them. This is especially true if the team is outsourced or distributed. A single location for critical documentation and communication is essential. For project execution, designate a single source, whether it is the project manager or a lead technical person, to be the single point of contact for any vendor issues. Clarify expectations for reporting, issue management and deliverables and penalties for not meeting those expectations. Get these agreements in writing.
Execution/Control:
§ Delegate, part two: The small-team approach allows a project team to remain flexible and not get bogged down in the minutiae. Even if a project is large in scale, the small team works effectively. Empower project or team leaders to manage tasks within their areas of expertise and work closely to keep communication open. Keep everyone on task by meeting formally on a weekly basis to review and measure against milestones, but meet daily on an informal basis to head off possible problems as quickly as possible.
§ Automate whenever possible: Make automation as accessible as possible. Use requirements management tools, such as Telelogic Doors or Borland’s Caliber RM, to track changes in scope or keep additional critical information centrally stored. Project management tools, from vendors such as Project Central, eLabor.com and Business Engine, allow team members to track time and issues that keep project managers and team members informed of progress and assist in avoiding miscommunications regarding objectives.
§ Collaborate, collaborate, collaborate: Team members perform much more effectively if they are in active communication with each other so that each dependency is clearly understood and managed. Hold weekly information sessions with the team to discuss issues, and collectively figure out correction strategies. If the team is scattered, use collaborative tools such as Webex, Placeware or Centra (see Planning Assumption, Comparing Team Collaboration Vendors on Their Functionality, Erica Rugullies) to hold meetings and share information. The method is not as important as the action itself. Keep everyone informed.
§ Use audits: To assess the health of the project, hold biweekly audit sessions, and check the status and progress of the project. Issues discussed during an audit are actual progress vs. work and cost estimates, requirements measurement for scope control and overall quality measurements in productivity. The actual audit process is very flexible; using the project charter as a guide, the team prepares criteria that measure the entire project, and then uses subsets of those criteria for assessment with each milestone. Short life-cycle projects can still benefit from audit sessions that ensure that precious time is not wasted. Keep them short and to the point, and refrain from personalization. Keep the focus on the project goals (see IdeaByte, Auditing Projects — The Long and Short of It, Margo Visitacion).
§ Measure productivity: You can’t improve if you don’t measure. Develop standard criteria for measurement, such as meeting deliverables, defect detection, resource utilization and rework, to find out where you can optimize or where you need to devote extra attention (see Planning Assumption, Update: Selecting Metrics and Using Them Effectively, Margo Visitacion).
§ Practice change control: Regardless of project size, if change control is not practiced, the project won’t meet deliverables and will miss delivery dates. Use software configuration management or requirements management tools to automate and manage the change process. Establish a chain of command for approving any scope change for the project. Formality depends on life cycle, but make sure that at least one business and technical lead is consulted for every change to estimate risk and duration of the changes (see IdeaByte, There’s More to Change Management Than Change Control, Margo Visitacion).
§ Test: It is critical to test early and often to ensure that the project is meeting deliverables and is production-ready. Hold walkthroughs, for example, end-user style demonstrations, peer-to-peer code inspections, information inspections, etc., at various stages of the project to ensure that the quality is built-in and that certification time is reduced. Allot time for user acceptance testing and beta testing whenever possible to minimize postproduction problems. At a minimum, testing should account for 15 percent of the project. If the technology is new or there are large amounts of system integration, plan for a minimum of 30 percent test time over the life of the project.
§ Design concise implementation procedures: Develop a step-by-step implementation plan that covers production test procedures, installation requirements as well as a contingency plan for problem management that includes back-out procedures and production support steps. Accompanying documentation must include release information: known problems, a high-level test plan (for production test prior to implementation) and contact information (see IdeaByte, Standardize Internal Software Implementations for Efficiency and Control, Margo Visitacion).
Closure:
§ Conduct a postmortem: This is the time to hash out any issues that will improve production support and improve process for the next project. Be sure to collect all project issues that caused any delays or restructuring of project focus, implementation issues and “morning after” support problems. Like audits and walkthroughs, these are not forums for personal criticism, but are used to analyze procedures for improvement.
§ Check temperature: Assess project success at several intervals after implementation to measure how well the project met expectations. This important metric delivers the foundation for future project growth. For example, if there are high levels of production support or rework, check the requirements and design processes; chances are, there was something critical missed during this phase where easy corrections were possible.
Alternative View
Adopting some practices for larger projects is suitable, but is too time consuming and inefficient for smaller projects. Borrowing from standard practices is fine, but project managers should not be tied to a rigid set of practices for unpredictable projects. Procedures should be tailored to the project.
Findings
If an organization has experience in developing various types of projects (but has little to no centralized project management), it should have a repository of organizational history to serve as a starting place to design procedures. Analyze current project practices, and perform a gap analysis between successful and challenged projects. Procedures that worked for previous projects may work for current procedures. Even in shorter development cycles, the process works by breaking down a successful method into its core objective, e.g., requirements management worked in previous projects because of strong stakeholder interviews.
Author : Margo Visitacion
References :
Related Giga Research
Planning Assumptions
Giga’s Framework for Project Selection and Prioritization, Margo Visitacion
Designing an
Comparing Team Collaboration Vendors on Their Functionality, Erica Rugullies
Update: Selecting Metrics and Using Them Effectively, Margo Visitacion
IdeaBytes
What to Include in a Feasibility Study, Margo Visitacion
Effective Risk Measurement in IT Projects, Jon Erickson
Auditing Projects — The Long and Short of It, Margo Visitacion
Code Reviews — Applications and Benefits, Margo Visitacion
Standardizing Internal Implementations for Efficiency and Control, Margo Visitacion
There’s More to Change Management Than Change Control, Margo Visitacion
Relevant Links and Other Sources
The Project Management Institute
