VBM - Vision Based Methodology™

Activity 2: Creating the Plan

A Time Tested Planning Approach

Plotting the HOW

Determining the individual steps of a workplan is truly the "core" activity in the plan building process. It also tends to cause incredible amounts of grief. Many important questions require answers during this process, and the quest for the "definitive approach" has kept methodology writers busy for years. Developing the workplan steps still remains a somewhat creative process. The ideas and ultimate approaches which are used to formulate the final phases, activities, and tasks in the plan, tend to come from these sources:

• The actual past experiences of the plan writer.
• The actual past experiences of an advisor or consultant to the plan writer.
• Duplication of past plans available to the plan writer which were deemed successful.
• Planning "templates" from either a commercial or an in-house project management package.
• Formal workplan steps from either a commercial or an in-house methodology.
• Some combination of some or all of the above sources.

If none of the above sources are available, the prospect of project failure begins to grow to significant dimensions. The only true resource at that point is the common sense and the good luck of the first time planner. This situation seldom, if ever, produces satisfactory results.

Another unfortunate situation is the plan writer who refuses to draw upon the available resources to aid in development of his or her plan. This "go it alone" approach overlooks some of the important benefits that either conferring with advisors or referencing methodologies can provide. Some of these potential advantages are:

Methodologies provide steps which are grounded in experience. These steps can be utilized as a "first cut" of the plan which can then be modified to suit the plan writer.

The risk of overlooking an important step or series of steps is reduced. The voice of experience from a colleague or the task checklist from a methodology can provide a valuable yardstick against which the potential plan can be compared.

Significant time savings can be realized when the plan does not have to be created from a blank sheet of paper. Having access to old plans for future cloning could turn out to be a wise as well as a productive decision.

Estimating HOW MUCH

Once the major tasks have been determined, an even more dreaded part of the planning process requires attention. Actual time estimates for each of the workplan tasks must be made. Putting the time to the task is an uncomfortable activity for some because it represents commitment, and this commitment is measurable!

Actually, making time estimates should be a natural and non-threatening part of the systems building process. Time estimates begin to give a clearer picture of the project in terms of human, financial, and technical resources. Without the benefit of a time basis, reasonable decisions about the merit and wisdom of the proposed project would be highly difficult. An important fact which needs to be realized is that the actual time expenditures during the project will vary from the estimate. This always happens and it makes the case for a "living workplan" or a plan which can be modified in response to changing project demands and conditions.

In order to make an accurate first cut at the time requirements for the proposed workplan steps, again all of the available resources should be marshalled and utilized. These include the following:

• Refer to past workplans for actual time consumption on similar tasks.
• Compare estimates to suggested time quantities from in-house or commercial methodologies.
• Discuss proposed tasks and allocated hours with project leaders who have had similar development experiences.
• Draw upon established estimating guidelines and procedures.

Using Past Development Metrics

Fred Brooks in his book The Mythical Man-Month points out that "it is very difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the managers." He goes on to state that "we need to develop and publicize productivity figures, estimating rules, and so on. The whole profession can only profit by sharing such data." He wrote that back in 1972 and still today the biggest problem many companies have is that no software development statistics have been collected for planning or comparison purposes. In addition to being able to make better estimates of proposed projects, some additional benefits of collecting development metrics are listed below:

Once a project is complete, the quantifiable benefits of the system can be measured against the actual system costs, and the true strategic payouts can actually be demonstrated. This can not only help in making the evaluation of each new project proposal more of a business decision exercise, it can also validate the claims of the past project sponsors.

The collection of development statistic assists in making the development process more predictable. This is especially true if some type of a repetitive methodology is used within the organization. Each new wave of metrics helps to fine-tune both the methodological and estimation processes.

So how do the system builders move from the "finger in the wind" estimation approach to one which is based on solid development metrics?

A Quick and Dirty Software Metrics Program

1. Use a common workplan approach for all projects (with steps that have similar names and meaning).
2. Select a standard workplan management package and require all project managers to use it to track man-hour utilization.
3. Specify a common set of statistics which are to be collected at the end of each project and compared to the man-hour expenditure:
   • Number of programs/modules (on-line, batch)
   • Number of screens/forms
   • Number of reports
   • Number of jobs
   • Number of databases/elements
   • Number of files
   • Number of entities/attributes
   • Number of processes
   • Number of objects/classes
4. Identify the automated tools (CASE), programming languages, code generators, and database management systems utilized by each project.
5. Determine the average man-hours required to produce each of the respective analysis, design, and construction components (don't be surprised at how high these can turn out to be!).
6. Continuously fine-tune and improve the resulting component/man-hour factors for future estimating needs.

Some Thoughts on Using Function Point Analysis

Spending lots of time an effort to do detailed function point analysis can be great as long as it is not just simply producing an appearance of a disciplined metrics program. If the front-line system planners are still asking: "OK, so how many hours should I estimate for a new on-line GUI program in such and such language?", and the answer is still not available, then the function point approach is a waste of time. It is just producing fancy charts for upper management presentations.

Determining WHO

After determining the tasks and the associated time requirements, the next major challenge is to specify who will be assigned to each task. At this stage it is better to make the assignments by title or resource type rather than by name. This allows for flexibility during the team building phase since available resources can be matched to the required resource types. Each individual task should be examined, and its unique staffing needs recorded. This resource assignment process should take into account the following factors:

• Determine how many people at each resource level will be required by task.
• Assign the resource types individually to each task.
• Allocate the total estimated time for each task across the assigned resource types.
• Build into the plan all foreseen administrative, meeting, and review time by resource type.
• Make adjustments to contemplated tasks, original time estimates, or proposed staffing on an as needed basis to insure reasonableness.

Once a first pass has been made to specify individual resource requirements, a "level loading" effort should be undertaken. This step should be iterative in nature, and its ultimate outcome should be a "balanced" assignment of individual resource types to each time period on a time unit basis, usually forty hours per week.

And Finally..Committing to WHEN

Now is the time to pull out the calendar and to begin circling proposed dates. Usually some type of a deadline already exists. If the project sponsors are willing to shell out the financing for the system - they have a habit of wanting it delivered by a specific date or within a certain time period. Consequently, high quality workplans must always incorporate target dates as a part of the fabric of the plan. This enforces rigor and builds reasonableness into the final result.

Step 1 should be to analyze each of the workplan steps in order to determine the activities which will fall into the critical path of the effort. These activities usually have both a high level of dependency (one must be completed before another can begin) as well as a somewhat obvious logical progression or order. The remaining non-critical activities usually are much more flexible when making workplan time period assignments.

Step 2 should be to use a forward based date assignment approach. One at a time, each workplan step should be assigned a specific begin and end date. Care should be taken that the critical path activities are first put into as streamlined and as short a time path as possible. The as the non-critical activities are examined, they should be timed to either fall along side the critical path activities, or if not enough manpower is available during the proposed time period, the critical path activities can be spaced further apart in order to free up resources to cover all of the anticipated activities.

Step 3 should be to establish major milestone deliverable dates based on the timing of the planned workplan steps. At selected points in the plan, formal tangible deliverables should be defined as a result of a previous series of workplan activities. These project milestones (as evidenced by the completion of the deliverables) can then be utilized as both a measurement of success for the business clients as well as a basis for the establishment of project deadlines for the project team.

Assumptions are Insurance

Once the plan is complete it's time to move right into more productive activities - like actually beginning to develop the system. However, one critical step still remains. Throughout the planning process many assumptions were undoubtedly made about such things as project team member abilities, number of programs, amount of client involvement, the planned technological environment, and the scope of the project team effort. A common mistake is to trust that anyone reading the workplan will perceive all of these underlying assumptions. Don't fall into this easily avoided trap! All significant assumptions should be clearly documented and made a part of the workplan. This accomplishes two important objectives:

• You have just written a project manager insurance policy! It will serve to prevent potential career limiting misunderstandings if any genuine project directional, personnel, or scope changes must be made after the effort is already well under way.
• It demonstrates an awareness of the important capability limitations and the significant areas of risk facing the project team. If the mission of the team must be altered, the original assumptions must be revisited and altered if necessary, in order to maintain a reasonable level of accountability for everyone involved.