REDUCED SCHEDULE AND COST APPROACH

This chapter has defined a great deal of work. If you attempt to do it alone,
you will never finish. If you attempt to be too precise, you will fail. The first sug-
gestion is to involve people in the business, IT, and your current vendor staff to
help in the analysis. This needs to be a collaborative effort. If they participate,
then there is more likelihood that they will support the results and be committed
to the project.
A second recommendation to speed things up is to generate outlines and
structures for documents and presentations at the beginning of the project.
Then esh these out as you go. A related idea is to market the results in an infor-
mal way to managers as you go. This will reduce the time it will take later for
them to understand what you have done and subsequently the time to gain
approval.
EXAMPLES
Millenium Manufacturing ultimately selected to do their own development.
Their decision was based on the fact that even though the new process simplified
the current process, there were still unique features that could not be addressed
by any existing software package.
Secour Retailing selected a package but did not do the analysis of the first step.
They roughly estimated costs and benefits and gained management support. The
package was later acquired and then found to be lacking in key features. The
result was extensive customization.
Roberts Agency, the transportation agency, performed the steps and
concluded that they would have to do both development and package
acquisition. There was no package that could handle certain functions; however,
if those functions were excluded, there was a package with a close fit.
LESSONS LEARNED
• Concentrate on no more than five sample transactions in defining the new
process. The detailed analysis for all transactions will be performed later.
• Identify the shadow systems and workarounds early. Get recognition of
these from the business department. This will gain their support for the new
process. Give attention to these in presentations to illustrate the shortcomings of the current system.
• Obtain a list of people who can review what you have done early on. This
includes a business staff member who can review the process work you do and the benefits and an IT person who can review architecture, technical
approach, schedules, and costs.
SUMMARY
In this chapter, you defined the overall new process along with requirements
and benefits. You then proceeded to develop estimates for costs, schedules, and
project plans. None of this will be complete. However, these are essential to make
the decision on what direction to take.
This chapter has defined major steps that must be taken prior to plunging into
development or software acquisition. If necessary, you should spend more time
here because every additional hour will likely save much more time later. The
steps have been defined in a linear way. However, you should consider starting
these in parallel and then building the end products in parallel.
WHAT TO DO NEXT
• For a current project that is underway—either a package implementation
or development project —review what has been done and what was done to
address the steps in this chapter. You will find that the steps were probably
not carried out overall. What impact has this had in terms of the project?
What surprises have surfaced?
• Practice carrying out the steps on a very small process within your depart-
ment. Walk through each step to determine what could be done. Ask the
following questions:
1. What political barriers would you face if you really did the work?
2. What is the condition of the current process and technology? To what
extent do business and IT staff recognize this?