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:
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:
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
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.
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:
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: