A solid project plan is a blueprint or a game plan that charts the entire project’s course. It should minimize the cost of rework by anticipating and addressing problems early in the project.
There is nothing more frustrating for a CIO than approving a project plan-only to find out months later that the recommended technology cannot be applied. To combat this, risk assessment is a
mandatory step in effective project planning.
The fundamental premise of good project management states that the project manager’s greatest challenge is effectively balancing the components of time, cost, scope, quality, and expectations.
Figure 1 shows the project diamond, which signifies this balance.
Figure 1: Project Diamond
The components of the project diamond have a symbiotic relationship. For example, when a user requests an additional report that wasn’t agreed on in the requirement specifications, the project’s
scope and quality change. This will change the other project components as well. As a result, the diamond’s shape will be skewed, graphically depicting a project out of control. The challenge is
managing change while keeping the diamond’s shape intact.
Project planning defines the diamond, while effective change and expectation management lets you manage it throughout the project’s life cycle. In this article, I’ll define a methodical approach
to assembling project plans.
This approach will help your team manage client and upper management expectations by accurately and effectively defining any project’s scope, cost, time, and quality dimensions. This process
combines pre-project discovery methods with proven management science techniques, and consists of the following steps:
- Performing your factor analysis
- Developing your project agreement
- Creating your change control procedures
- Developing your work breakdown structure
- Estimating the tasks
- Creating the schedule
- Performing risk assessment
Performing Your Factor Analysis
In the Seven Habits of Highly Effective People (Covey Leadership Center, 1998) author and management scientist Steve Covey writes, “To be understood, you must seek to understand.” Often, from the
moment a project is initiated, developers make assumptions about the effort ahead and how to attack it. Too often, they leap to conclusions about projects-to the point of preparing plans or
estimates based largely on invalid or incomplete information-and the project fails to meet its budget, objective, and schedule expectations.
Sooner or later (usually later) in the development process, the conditions you should have discovered in the planning process, like choosing the right mix of human resources, become apparent, and
the project efforts-or deliverables-suffer. How many times have you completed a documentation task only to realize that a technical writer would have performed it better than the programmer?
Factor analysis is a disciplined technique for investigating, analyzing, and understanding a project-before you make commitments. Similar to requirements analysis in a standard development
methodology, factor analysis questions should not only focus on system requirements but also the environmental issues surrounding the project. These issues include: What is the project’s scope?
Are all client personnel committed to the project? What is the acceptance criteria? How will I communicate project status? Often, a good factor analysis will lead to the inclusion of a technical
requirements analysis phase in the system development effort.
This process consists of 10 key factors or elements of every project. Once you understand them, you and your team can explore each element’s impact on the project and the appropriate project
deliverables. Performing a factor analysis removes much of the mystery from planning and estimating future events. It is a structured, critical first step in confirming what you know and exposing
what you don’t know about a project.
Following are the 10 factors of every project. As you gather information about the specific factors, it’s important to document expectations, constraints, and associated issues to consider during
subsequent planning activities.
- Definition/Scope: The primary project’s purpose, including major functions and deliverables, and the purpose of the project relative to the organizational whole
- Resources: The financial, technical, material, and human resources you need to support or perform the project
- Time: Elapsed time and actual work time required to complete the project
- Procedures: The various organizational requirements: policies and procedures, methodologies, quality program, work request initiation, financial review, and so on
- Environment: The project’s entire cultural, political, geographical, physical, and technical context
-
Change: New or different future conditions, requirements, events, or constraints discovered within or imposed on the project-and the associated procedures for managing project
change - Communications: Meetings, status reports, presentations, and complexities that will affect communication
- Commitment: The degree of sponsor, user, and other stakeholder support
- Expectations: Business, productivity, operational, cultural, or any other performance changes you expect as a result of project implementation
- Risk: The potential jeopardies to project success and, conversely, the jeopardies associated with not doing the project or some aspect of the project.
Develop Your Project Agreement
The project agreement is the contract or proposal that defines the work you need to do in terms of the project diamond. In addition, project agreements document the project schedule by depicting a
work breakdown structure-the foundation for accurate estimates, task dependencies, and eventually a critical project path.
It is important to negotiate project agreements so that the client and the project manager agree on the work needed and the schedule to accomplish it. Stakeholders should understand their
requirements, but they might not grasp the time frames and cost for development and implementation. The project manager must be comfortable debating all of the diamond’s components. The ultimate
goal should be a mutual understanding of the diamond’s dimensions.
This creates buy-in on both sides.
Creating Change Control Procedures
A project can change at any time. For example, new requirements can be introduced. Change management is simply the process of analyzing and evaluating potential changes in the project’s scope,
schedule, quality, or cost for orderly integration into the project plan. The project manager’s role is not just to implement customer requirements but also to assist and facilitate in the impact
assessment of all change items. The project manager must work with the client to make good business decisions. The change process, which you must document in the project agreement, is the vehicle
to advance this.
A universal truth applies to any project: change will occur constantly, dynamically, and usually, without warning. “Freezing” requirements is a popular, though rarely feasible, approach to
controlling the inevitable. A good project manager recognizes the inevitability of change and plans for effective change management.
Effective project management anticipates change and the calculated reaction to it. Ineffective change management will blur the boundaries of when and what is to be delivered. If you don’t plan for
change, the ground will be well-tilled for poisonous project weeds and skewed expectations.
Since my definition of quality is “conformance to customer requirements,” the process of evaluating and communicating the effects of change with the client is fundamental to a strong project
management process.
Developing Your Work Breakdown Structure
Creating a work breakdown structure is integral to planning, estimating, scheduling, and managing a project. It is the process of decomposing a project into its detailed work tasks, and logically
arranging these tasks to accomplish the project’s objectives. This includes identifying the phases, deliverables, and activities you need to accomplish project objectives.
The lowest level of a work breakdown structure provides the basis for estimating and cost-tracking. It’s generally the most reliable level in which to estimate. More often than not, poor estimates
reflect missing tasks, rather than poorly estimated, known tasks. Without a comprehensive work breakdown structure, you can’t measure or predict project progress, costs, and accountability.
Moving down the hierarchy represents an increasing amount of work detail. The lowest detail level tasks are called work packages. Work packages are the units you schedule the project work by. You
use the higher- or summary-level tasks for project sizing and negotiation, cost accounting, and management and customer status reporting. You also define project milestones in the work breakdown
structure. Milestones are major events or points in time that you’ll measure your progress against.
Figure 2 depicts a work breakdown, or decomposition, diagram. It shows the typical work breakdown structure numbering convention.
Figure 2: Typical Work Breakdown Diagram
Estimating the Tasks
You must estimate the approximate time and costs you need to complete the project you described in the work breakdown structure, and in accordance with environmental constraints you identified
during factor analysis. Preparing estimates of time and cost can be difficult for project managers. If you follow factor analysis and work breakdown structure principles properly, you’ll develop
estimates with greater confidence.
Most estimate problems are caused by failing to identify all the necessary tasks, not from poor time estimation of the identified tasks. You cannot estimate time or costs for tasks that have not
been identified. You can develop estimates at various levels of detail. You can develop planning approximations for budgetary purposes with higher-level work breakdown structures than contract
estimates for billing. In general, estimates prepared at the lowest level of the work breakdown structure are more reliable and accurate than estimates prepared at the higher levels.
Project managers often have problems because they don’t compensate for a few basic estimating concepts. For example, it may take 40 hours to complete a programming task. This does not necessarily
mean the task duration will last one week. If a programmer is in high demand and divided between two projects, this task could actually take two weeks. If a vacation week falls in those two weeks,
it may take three weeks to complete this 40-hour task.
The time you spend estimating a project may be a small percentage of the total project time. It is still important to document the estimate, because it not only lets you improve the standard (for
future estimates), it also lets you teach the estimating process to someone else.
Creating the Schedule
Once you identify all the project tasks and establish their duration, you can assign staff resources, derive task dependencies, and then develop the subsequent schedule. Scheduling is the process
of varying scope, time, resource, and risk constraints to select and document the optimum project time and staff schedule. The project schedule will be your primary tool for monitoring the project
life cycle’s progress. You must revise it periodically to reflect the inevitable changes I discussed earlier.
Scheduling, like estimating, occurs throughout the project life cycle. First, create the initial schedules to negotiate the project agreement. Then, each time the project changes, you complete the
work breakdown structure and associated estimates and rework the schedule. This includes analyzing the tasks and resource requirements to determine their impact on the remaining project.
Once you assemble the schedule, you should clearly understand the critical path. The project’s critical path will determine the project completion date. The critical path has the least amount of
float (or 0 float days) of all paths, and has the longest elapsed time of all paths.
In summary, any task on the critical path that slips its completion date will make the project’s end date slip as well. Thus, tracking the critical path will help you determine whether or not your
project will end on time. Equally important, tasks on the critical path may not be the most “project critical tasks.” Critical path is a management science concept that only addresses the time
dimension of the diamond. Contrary to popular belief, not all projects are time critical. The critical path may not be the place where you should spend the majority of your time. Critical path
tasks, for example, might be documentation activities, while design and programming fall on paths with float.
You may choose to spend the bulk of your time monitoring the design and programming activities while letting the documentation specialists inform you of any potential time delays.
Perform Risk Assessment
Risk is an inherent component of project management. Whenever you undertake any project, you expose yourself to risk. Project risk is anything that will adversely affect project objectives. Risk is
the possibility of incurring some harm and therefore is related to the potential occurrence of some events.
When assessing risk, consider these three factors:
- The risk event itself
- The event’s probability
- The effect’s potential severity.
Risk management is the process of identifying, analyzing, and responding to risk throughout the project’s life cycle. This response should take the form of contingency plans-additional tasks built
into the work breakdown structure to mitigate a risk event, deflecting the risk items to another entity, and so on.
|
Table 1. Risk Scenario Example |
|
| Risk Event: | What if we don’t have the resources to implement the new technology when it’s needed late in the project? |
| Risk Probability: |
75% chance the resources will not be available 90% chance the resources, if available, will perform poorly |
| Impact: |
The project will not complete on time, quality of the final product will be compromised if the new technology is not installed properly. |
| Response: | Find a qualified subcontractor to assist or perform the new technology implementation. |
For example, a project team is developing a system that calls for the implementation of new technology. The team has the resources necessary to develop the system but fears it lacks the resources
to implement the new technology. The risk scenario would look something like Table 1. As you can see, the response in Table 1 will have a major impact on your project agreement. This adds greater
complexity to the project and affects the cost by adding tasks to the work breakdown structure. In addition, it will affect the quality of the system you install. At a minimum, you should use this
type of analysis for all risk events with a high probability of occurrence and a high degree of impact.
Manage the Diamond by Managing Expectation
Effective project planning is not conducted in a vacuum. It must be carried out in coordination and cooperation with all appropriate stakeholders. You must manage their expectations throughout the
process. The project manager must constantly look for opportunities to create win-win relationships by negotiating the work that must be accomplished. A project manager who declares that “this
can’t be done in the time frame allotted” will meet with stiff resistance from client management. On the other hand, a project manager who can defend this statement with a solid understanding of
the project’s scope, backed by a logical work breakdown structure; thoughtful estimate; thoughtful estimate and project schedule; and concise risk analysis will be met with a response like,
“Maybe you’re right. Help me understand what you understand.”
This is effective expectation management and proper development of win-win relationships. Once your project plan is in place, it’s easy to simply manage your project diamond.
Copyright © 1999 Software Development magazine
