project Management

Project Management Best Practices: Key Processes and Common Sense ♦ Margo Visitacion
Planning Assumption ♦ RPA-012003-00030 ♦ www.gigaweb.com
© 2003 Giga Information Group, Inc.
Page 3 of 6
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
Project Management Best Practices: Key Processes and Common Sense ♦ Margo Visitacion
Planning Assumption ♦ RPA-012003-00030 ♦ www.gigaweb.com
© 2003 Giga Information Group, Inc.
Page 4 of 6
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
Project Management Best Practices: Key Processes and Common Sense ♦ Margo Visitacion
Planning Assumption ♦ RPA-012003-00030 ♦ www.gigaweb.com
© 2003 Giga Information Group, Inc.
Page 5 of 6
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.