Page 121 -

88 Part 1 • SyStemS analySiS FundamentalS

similarities, there are also many differences. One difference is that the data used by ecommerce
systems are scattered all over an organization. Therefore, you are not just managing data in a
self-contained department or even one solitary unit. Hence, many organizational politics can
come into play because units often feel protective of the data they generate and do not understand
the need to share them across the organization.
Another stark difference is that ecommerce project teams typically need more staff with a variety
of skills, including developers, consultants, database experts, and system integrators, from across the
organization. Neatly defined, stable project groups that exist within a cohesive IS group or systems
development team are the exception rather than the rule. In addition, because so much help may be
required initially, ecommerce project managers need to build partnerships externally and internally
well ahead of the implementation, perhaps sharing talent across projects to defray costs of ecom-
merce implementations and to muster the required numbers of people with the necessary expertise.
The potential for organizational politics to drive a wedge between team members is very real.
One way to prevent politics from sabotaging a project is for the ecommerce project manager
to emphasize the integration of the ecommerce system with the organization’s internal systems
and in so doing emphasize the organizational aspect embedded in the ecommerce project. As one
ecommerce project manager told us, “Designing the front end [what the consumer sees] is the
easy part of all this. The real challenge comes from integrating ecommerce strategically into all
the organization’s systems.”
A fourth difference between traditional project management and ecommerce project man-
agement is that because the system will be linking with the outside world via the Internet, secu-
rity is of the utmost importance. Developing and implementing a security plan before the new
system is in place is a project in and of itself and must be managed as such.

Creating a Project Charter
Part of the planning process is to agree on what will be done and at what time. Analysts who are
external consultants, as well as those who are organization members, need to specify what they will
eventually deliver and when they will deliver it. The entire team as well as the client need to be on
board. This chapter has elaborated on ways to estimate the delivery date for the completed system
and also how to identify organizational goals and assess the feasibility of the proposed system.
The project charter is a written narrative that clarifies the following questions:
1. What does the user expect of the project (that is, what are the objectives)? What will the
system do to meet the needs (achieve the objectives)?
2. What is the scope (or what are the boundaries) of the project? (What does the user consider
to be beyond the project’s reach?)
3. What analysis methods will the analyst use to interact with users in gathering data and
developing and testing the system?
4. Who are the key participants? How much time are users willing and able to commit to
participating?
5. What are the project deliverables? (What new or updated software, hardware, procedures, and
documentation do the users expect to have available for interaction when the project is done?)
6. Who will evaluate the system, and how will they evaluate it? What are the steps in the
assessment process? How will the results be communicated, and to whom?
7. What is the estimated project timeline? How often will analysts report project milestones?
8. Who will train the users?
9. Who will maintain the system?

The project charter describes in a written document the expected results of the systems proj-
ect (deliverables) and the time frame for delivery. It essentially becomes a contract between the
chief analyst (or project manager) and the analysis team, with the organizational users requesting
the new system.

The Systems Proposal

While the project charter serves the purpose of identifying objects, determining scope, and
assigning responsibilities, an analyst still needs to prepare a systems proposal that includes much
of the detail about system needs, options, and recommendations. This section covers both the
content and style that make up a systems proposal.