PM Milestone Project Management Templates

PM Milestone 7000 Project Management Templates

Get Instant Access

Implements- \

tion J

Maintenance\ & support J

i \

Figure 1.3 Systems Development Life Cycle

Figure 1.3 Systems Development Life Cycle

Planning The planning stage involves identifying and responding to a problem or opportunity and incorporates the project management and system development processes and activities. Here a formal planning process ensures that the goal, scope, budget, schedule, technology, and system development processes, methods, and tools are in place.

Analysis The analysis phase attempts to delve into the problem or opportunity more fully. For example, the project team may document the current system to develop an "as is" model to understand the system currently in place. In general, systems analysts will meet with various stakeholders (users, managers, customers, etc.) to learn more about the problem or opportunity. This work is done to identify and document any problems or bottlenecks associated with the current system. Generally, the "as is" analysis is followed by a requirements analysis. Here the specific needs and requirements for the new system are identified and documented. Requirements can be developed through a number of means—interviewing, joint applications development (JAD), conducting surveys, observing work processes, and reading company reports. Using process-oriented, data-oriented, and/or object-oriented modeling techniques, the current system, user requirements, and logical design of the future system called the "to be" system are represented and documented (Dennis and Haley 2000).

Design During the design phase, the project team uses the requirements and "to be" logical models as input for designing the architecture to support the new information system. This architecture includes designing the network, hardware configuration, databases, user interface, and application programs.

Implementation Implementation includes the development or construction of the system, testing, and installation. In addition, training, support, and documentation must be in place.

Maintenance and Support Although maintenance and support may not be a true phase of the current project, it is still an important consideration. Once the system has been implemented, it is said to be in production. Changes to the system, in the form of maintenance and enhancements, are often requested to fix any discovered errors (i.e., bugs) within the system, to add any features that were not incorporated into the original design, or to adjust to a changing business environment. Support, in terms of a call center or help desk, may also be in place to help users on an as-needed basis.

Eventually, the system becomes part of the organizational infrastructure and becomes known as a legacy system. At this point, the system becomes very similar to a car. Let's say you buy a brand new car. Over time, the car becomes less and less new, and parts have to be replaced as they wear out. Although, a system does not wear out like a car, changes to the system are required as the organization changes. For example, a payroll system may have to be changed to reflect changes in the tax laws, or an electronic commerce site may have to be changed to reflect a new line of products that the company wishes to introduce. As the owner of an older or classic car, you may find yourself replacing part after part until you make the decision to trade in the old junker for something newer and more reliable. Similarly, an organization may find itself spending more and more on maintaining a legacy system. Eventually, the organization will decide that it is time to replace this older system with a newer one that will be more reliable, require less maintenance, and better meets its needs. Subsequently, a new life cycle begins.

Putting the SDLC into Practice

There are basically two ways to implement the SDLC. Today, an IT project will follow either a structured approach or a newer approach called Rapid Applications Development (RAD).

Structured Approach to Systems Development A structured approach to systems development has been around since the 1960s and 1970s when large mainframe applications were developed. These applications were built when (1) systems were relatively simple and independent from each other, (2) computer hardware was relatively more expensive than the labor, and (3) development and programming tools were primitive compared to today (Satzinger, Jackson, Burd 2002).

The Waterfall method in Figure 1.4 follows the SDLC in a very sequential and structured way. Planning overhead is minimized because it is all done up-front and a tangible system is not produced until the end of the life cycle (McConnell 1996). The idea of a waterfall is a metaphor for a cascading of activities from one phase to the next. This approach stresses a sequential and logical flow of development activities. For example, the design activities begin only after the analysis and requirement activities are complete. Subsequently, the actual development, or programming activities, will not start until the design phase is complete. Although one can go back to a previous stage, it is not always easy or desirable.

This approach is suitable when developing structured systems and assumes, or at least hopes, that the requirements defined in the analysis stage do not change very much over the remainder of the project. In addition, because it will provide a solid structure that can minimize wasted effort, this method may work well when the project team is inexperienced or less technically competent (McConnell 1996).

Rapid Applications Development (RAD) On the other hand, one can take a less-structured approach to developing systems. Today, taking less time to conceive,

Figure 1.4 Waterfall Model

develop, and implement an information system can provide the organization with a competitive advantage. In addition, as evidenced by the CHAOS study, larger projects that take longer to develop are riskier than smaller and shorter projects. Satzinger, Jackson, and Burd (2002, 533) define RAD as "a collection of development approaches, techniques, tools, and technologies, each of which has been proven to shorten development schedules under some conditions." This means that different development approaches, tools, techniques, and so forth can be mixed and matched depending on the project. For some projects, it means that the Waterfall approach is the most appropriate; however, RAD often follows one of the following iterative approaches:

• Prototyping—Prototyping is an iterative approach to systems development where the developer and user work together very closely to develop a par tially or fully functional system as soon as possible, usually within a few days or weeks. The prototype application will go through a number of itera tions as functional requirements are defined or changed. This approach is most useful when the requirements of the new system are difficult to define or when working with a new technology where the capabilities of that tech nology are unknown or not understood very well. A prototype may be either a throwaway system or a fully usable system. A throwaway prototype may be used to discover or refine system requirement specifications that can be used as a model for developing the real system. On the other hand, the prototype may become the actual system after it has gone through a number of refinements over time.

• Spiral Development—Another way to expedite the SDLC is the spiral approach first proposed by Barry Boehm (1988). The spiral model provides a risk-oriented approach where a software project is broken up into a num ber of miniprojects where each addresses one or more major risks until all major risks have been addressed (McConnell 1996). A risk can be defined as a poorly understood requirement or architecture or as a potential prob lem with the technology or system performance. The basic idea is to begin development of the system on a small scale where risks can be identified. Once identified, the development team then develops a plan for addressing these risks and evaluates various alternatives. Next, deliverables for the iteration are identified, developed, and verified before planning and com mitting to the next iteration. Subsequently, completing each iteration brings the project closer to a fully functional system. Reviews after each iteration provide a means of controlling the overall risk of the project. Major prob lems or challenges will surface early in the project and, therefore, provide the potential to reduce the total cost of the project. The disadvantages to the spiral development approach center on its complexity (Satzinger, Jackson, Burd 2002). These types of projects are more complex to manage because many people may be working on a number of different parallel activities.

• Extreme Programming (XP)—Kent Beck introduced the idea of XP in the mid-1990s. Under XP, the system is transferred to the users in a series of versions called releases. A release may be developed using several itera tions and should be developed and tested within a few weeks or months. Each release is a working system that only includes one or several func tions that are part of the full system specifications. XP includes a number of activities where the user requirements are first documented as a user story. The user stories are then documented using an object-oriented model called the class diagram, and the release is developed over the course of several iterations. A set of acceptance tests for each user story is then developed. Releases that pass the acceptance test are then considered complete. XP provides the continuous testing and integration of different software modules and components while supporting active user involvement. In addition, XP often incorporates team programming where two programmers work together on the same workstation. Small teams of developers often work in a common room where workstations are positioned in the middle and workspace for each team member is provided around the perimeter. Developers often are prohibited from working more than 40 hours a week in order to avoid burnout and the mistakes that often occur because of fatigue (Satzinger, Jackson, Burd 2002).

The PLC versus the SDLC

You may be still wondering about the difference between the project life cycle and the systems development life cycle. Although they may seem to be quite similar, the difference is that the product life cycle focuses on the processes of managing a project, while the SDLC focuses on creating and implementing a product—the information system. In this text we will focus primarily on the PLC, although the SDLC and the particular approach we choose will have a direct bearing on the project's scope (i.e., the deliverables that the project team must provide) and the work activities needed to produce those deliverables. Consequently, the number of activities, their sequence, time-to-complete, and resources required will directly determine the project's schedule and budget.

As illustrated in Figure 1.5, the SDLC is really part of the PLC because many of the activities for developing the information system occur during the execution phase. The last two stages of the PLC, closing and evaluating the project, occur after the implementation of the information system.

The integration of project management and system development activities is one important component that distinguishes IT projects from other types of projects. A

methodology will be presented in Chapter 2 and will illustrate how the project life cycle and systems development life cycle can be combined to manage the process and product of IT projects. This methodology will provide a foundation for the concepts, processes, tools, and techniques throughout this text.


As was mentioned earlier, the Guide to the Project Management Body of Knowledge is a document available from the Project Management Institute (PMI) — an international, nonprofit, professional organization with more than 55,000 members worldwide. The original document was published in 1987, and the updated version provides a basis for identifying and describing the generally accepted principles and practices of project management. However, as PMBOK is quick to point out, "generally accepted" does not mean these principles and practices work the same way on each and every project. It does mean that many people over time believe that these principles and practices are useful and have value. Determining what is appropriate is the responsibility of the team and comes from experience. (Perhaps experiences that can be documented and shared?)

This text will use the PMBOK Guide as a foundation but will also integrate a number of concepts and ideas that are part of the body of knowledge that makes up the field of information systems. Ideally, you will then understand not only what many IT project managers and organizations throughout the world think are important, but also the language and the processes.

PMI provides a certification in project management through the Project Management Professional (PMP) certification exam. This text can also help you prepare for the PMP certification exam. To pass, you must demonstrate a level of understanding and knowledge about project management, satisfy education and experience requirements, and agree to and adhere to a professional code of ethics.

Project Management Knowledge Areas

The Guide to the Project Management Body of Knowledge defines nine knowledge areas for understanding project management. These nine knowledge areas are illustrated in Figure 1 .6 and will be covered in more detail in later chapters.

• Project Integration Management — Integration focuses on coordinating the project plan's development, execution, and control of changes.

• Project Scope Management—A project's scope is the work to be completed by the project team. Scope management provides assurance that the pro ject's work is defined accurately and completely and that it is completed as planned. In addition, scope management includes ways to ensure that proper scope change procedures are in place.

• Project Time Management — Time management is important for developing, monitoring, and managing the project's schedule. It includes identifying the project's phases and activities and then estimating, sequencing, and assign ing resources for each activity to ensure that the project's scope and objec tives are met.

• Project Cost Management — Cost management assures that the project's budget is developed and completed as approved.

Figure 1.6 Project Management Body of Knowledge (PMBOK)

Project Quality Management—Quality management focuses on planning, developing, and managing a quality environment that allows the project to meet or exceed stakeholder needs or expectations. Project Human Resource Management—People are the most important resource on a project. Human resource management focuses on creating and developing the project team as well as understanding and responding appropriately to the behavioral side of project management. Project Communications Management—Communication management entails communicating timely and accurate information about the project to the project's stakeholders.

Project Risk Management—All projects face a certain amount of risk. Project risk management is concerned with identifying and responding appropriately to risks that can impact the project.

Project Procurement Management—Projects often require resources (people, hardware, software, etc.) that are outside the organization. Procurement management makes certain that these resources are acquired properly.

Was this article helpful?

0 0
Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment