IT510 Advanced Information Technology

IT 510 Module Two 1

Module One introduced the role of a systems analyst and the overall process flow of a

project. Module Two will present details of creating and managing a project plan. Many

organizations have a department in IT dedicated to project management called a Project

Management Office (PMO). The team is staffed with PMPs that typically run three to five

projects concurrently. A project manager follows a defined project management

methodology, which includes phases similar to those described below.

The first phase, initiation, is the phase in which the project is defined and approved to

initiate. High-level dollar and resource budgets are estimated and management approval

occurs in this phase of the project methodology. Phase two is planning. Following the

approval, an initial planning phase begins to put tasks and timelines with cost and resource

budgets. Management works with the project manager at this level to develop the planning

for the project. Management approval is needed to complete this phase so that resources

can be committed. The third phase is executing. Following the approval of the planning

phase, the project begins executing. Resources are assigned, dollar purchases for hardware

and software are made, and the project is underway. Controlling, the fourth phase, runs

concurrently with executing and is an overseeing method to ensure that the execution is on

time and on budget. As the project hits issues and requires adjustments, the controlling

phase has tools and techniques to replan and continue moving forward. The final phase is

closing. After the project has been delivered to production and execution is completed, the

closing phase begins. In closing, the project is wrapped up and all resources are released

and lessons learned are documented.

A systems analyst is typically part of phase two, the planning phase, and phase three, the

executing phase. The systems analyst will have separate, individual tasks, and project

management controls for the systems analyst’s tasks as part of the larger executing phase.

The systems development life cycle (SDLC) also falls into the planning and executing

phases in most methodologies.

2 IT 510 Module Two

Project Triangle

In a project, there are three constraints that must be managed: cost, scope, and time. If you

consider the three elements as a triangle, it would mean that only one of the three can be

constrained while the other two would have to move. For example, imagine there is an

approved project with a fixed cost of $1,000 to deliver a scope of 100 widgets in 30 days.

Then, as the project is executing, the customer requests 150 widgets. Since the customer’s

request changes the scope, either the cost or time has to change when considering the rule

of the triangle. If the company holds cost, the number of days will need to be extended. If the

company holds time, then there is additional cost needed to complete the additional work.

While this is a basic example, in a real project, any issues with the scope can eradicate a

project plan. When one has months or years of development, it is very easy to add small

changes such as new screen fields or data elements. Over time these small changes

accumulate and cause an impact to date timelines or cost.

Project Scheduling and Control

Scheduling a project requires a variety of methods and techniques. A project manager must

be highly skilled in the area of scheduling. For systems analysts, the need to schedule and

control aspects of their work does not require the same level of knowledge as project

managers. However the same methods and techniques apply.

A systems analyst will first need to develop a work breakdown structure (WBS). This is a

high level organization of the work to be completed. Tasks are then added to the WBS.

Tasks are the actions to perform and are verbs. Once you have the WBS and its tasks

defined, you then begin to connect them in a logical order. Some tasks require that a

predecessor task completes before they can start. When we define tasks according to these

project management rules, as the project progresses and is being tracked, the successor

tasks will continue to reschedule as the predecessor tasks complete.

As the systems analyst tracks the completed tasks and manages the current tasks, the

analyst continually adjusts the future tasks of the project plan as well. For example, if the

plan was scheduled to complete data design in ten days and the design was completed in

five days, the plan gained five days. However, gaining five days does not mean the project

will end five days earlier. The schedule is a very complex network of tasks, so being able to

read a project schedule in Microsoft Project will help the systems analyst control the project.

When controlling a project, the systems analyst needs to focus on completing each planned

task, while adding tasks that were not initially planned, and still make the target delivery

dates. The target deliveries are typically defined as milestones. The milestone dates will be

IT 510 Module Two 3

the dates that something must be delivered. In a typical project plan, a milestone may be

three months from the starting point. The systems analyst should expect that there will be

scope increases and decreases based on the execution of work tasks. However, the

milestone is an anchor target date that the team should try not to move. Project

management and control is the execution portion of project management methods and

techniques that are needed to make the milestone date.

For the purpose of the course, it is important to understand the concepts of project

management and the systems analyst role. Note that the fundamentals explained in the

course are an introduction to project management concepts. Through further studies, which

are structured specifically on project management, students will learn the application of

project management techniques and methods. In Module Three, students will begin to

design the system using object oriented modeling. Object oriented modeling is an approach

that identifies system objects, classifies system objects, defines system objects, and

describes the attributes and behaviors of system objects. Using object oriented design, the

systems analyst can build out small pieces of the system independently of each other before

integrating into a full system design and architecture.