dolution

Once deployed, what are the potential operational risks of the proposed system? How do you factor operational risks into a systems development plan?

Chapter 5: Initiating and Planning Systems Development Projects

Now that the “No Customer Escapes” project team has been formed and a plan has been developed for distrib- uting project information, Jim can begin working on the project’s scope statement, workbook, and Baseline Proj- ect Plan. He first drafted the project’s scope statement and posted it on the project’s intranet (see PE Figure 5-1). Once posted on the intranet, he sent a short e-mail mes- sage to all team members requesting feedback.

Minutes after posting the project charter, Jim’s office phone rang.

“Jim, it’s Sally. I just looked over the scope statement and have a few comments.”

“Great,” replied Jim, “It’s just a draft. What do you think?”

“Well, I think that we need to explain more about how the system will work and why we think this new system will more than pay for itself.”

“Those are good suggestions; I am sure many others will also want to know that information. However, the scope statement is a pretty high-level document and doesn’t get into too much detail. Basically, its purpose is to just for- mally announce the project, providing a very high-level description as well as briefly listing the objectives, key as- sumptions, and stakeholders. The other documents that I am working on, the workbook and the Baseline Project Plan, are intended to provide more details on specific deliverables, costs, benefits, and so on. So, anyway, that type of more detailed information will be coming next.”

“Oh, OK, that makes sense. I have never been on a proj- ect like this, so this is all new to me,” said Sally.

“Don’t worry,” replied Jim, “Getting that kind of feed- back from you and the rest of the team will be key for us doing a thorough feasibility analysis. I am going to need a lot of your help in identifying possible costs and ben- efits of the system. When we develop the Baseline Proj- ect Plan, we do a very thorough feasibility analysis—we examine financial, technical, operational, schedule, legal and contractual feasibility, as well as potential political is- sues arising through the development of the system.”

“Wow, we have to do all that? Why can’t we just build the system? I think we all know what we want,” replied Sally.

“That is another great question,” replied Jim. “I used to think exactly the same way, but what I learned in my last job was that there are great benefits to following a fairly formal project management process with a new system. By moving forward with care, we are much more likely to have the right system, on time and on budget.”

“So,” asked Sally, “what is the next step?”

“Well, we need to do the feasibility analysis I just men- tioned, which becomes part of the project’s Baseline Project Plan. Once this is completed, we will have a walk-through presentation to management to make sure they agree with

and understand the scope, risks, and costs associated with making ‘No Customer Escapes’ a reality,” said Jim.

“This is going to be a lot of work, but I am sure I am going to learn a lot,” replied Sally.

“So, let me get to work on the feasibility analyses,” said Jim. “I will be sending requests out to all the team mem- bers to get their ideas. I should have this e-mail ready within an hour or so.”

“Great, I’ll look for it and respond as soon as I can,” answered Sally.

“Thanks, the faster we get this background work done, the sooner we will be able to move on to what the system will do,” replied Jim.

“Sounds good, talk to you later. Bye,” Sally said.