ELT Project Management Presentation by Bob Morlock

Project Management

April 26, 2005

Between Now and Lunch Before we begin. What is Project Management? The Project Management Triangle. Project Methodology The Project Life Cycle The “Movie” Planning and Establishing the Project

Baseline. Roles and Responsibilities Where Do Projects Fail? Is IT Really Different Questions?

Before We Begin

Project Management usually takes between 4 and 8 weeks of intensive training.

Another 2 – 3 years to apply that knowledge.

The information given here in the next 3 hours is an abridged version, covering the basics.

What is Project Management?

Project management is a set of principles, practices, techniques, and facilitation of the planning, scheduling, and control of all activities that must be done to meet project objectives. It is a disciplined way of organizing a job and leading a team to help control costs, manage scope, performance, and outcomes and also to mitigate risks.

Project Management (Cont.)

There are two aspects of Project Management: What and How. The “What” is the task to be performed. The “How” relates to the “process” used

to reach the desired outcome. Process includes both the solving of the task itself, and how the team functions in total – how they interact, solve problems, make decisions, run meetings, and every other aspect of team performance.

Project Management (What)

The What -- every project has three primary goals: To create something (like a product,

procedure, process or other deliverables).

Deliverables are those clearly defined results, goods or services produced during the project or at its outcome.

To finish all tasks within an agreed upon schedule.

To complete the project within an established budget.

Project Management (What cont.)

Secondary goals are goals other than the primary goals that must be specified to actually define the project, sometimes referred to as objectives and/or outcomes that are mutual expectations and define the scope of work.

Project Management (How)

Process (How) will always affect task performance (What). In manufacturing, managers have studied

every step of their process to eliminate non-value-added steps, to reduce scrap and re-work, and to optimize the process as much as possible.

This same kind of scrutiny can improve non-manufacturing processes as well, to allow faster, smoother processes that can drastically improve task performance and produce a more consistent process.

Project Management (How cont.)

Most projects fail from the beginning because they are not clearly defined and poorly planned. Processes are ignored in favor of speed to complete the project – The drive to “just get it done”.

If we do not have good processes, any tools used will only help us to document failures with great precision.

Organizations and project teams consist of people. Yet so much time is used for managing the physical resources, inventory, tools, schedules, status reports, and other activities which takes time from the project, that the "people" part is easily overlooked. And, if people do not perform well, neither will the processes and the project's outcome suffers.

Project Management (How cont.)

All the people within a project (programmers - for an IT project, Sponsors, business personnel, etc.), their performance, and their communication are part of the Businesses culture.

Culture comprises accountability, communications, ownership, learning, and embracing change.

Culture is related to people. It describes the sum total of the values, attitudes, traditions, and behaviors that exist in an organization. One way to know when people are talking about their culture is when they say, "We don't do it that way here."

The Project Management Triangle

Project management control can only be achieved when cost, time, performance objectives and scope are clearly documented, realistically derived, and deliberately managed.


When managing any project, there are four constraints you must take into consideration. These constraints apply to both large and small projects. Performance (P) refers to the project's

requirements and objectives and the quality level of each. What results must the project produce? What features should it have? What will be needed to meet the customer's satisfaction? What are the deliverables and outcomes?

Cost (C) refers to the labor cost to do a job. (This may or may not include capital equipment and material costs which may by accounted for separately.)

Time (T) refers to the time required to complete the project.

The area of the triangle adds another constraint: scope (S). Scope is the amount of work that must be done to complete the project; it is the magnitude of the job.

The Project Management Triangle (cont)

The Project Management Triangle (cont)

When one of these constraints changes, at least one of the others must change, too, to compensate. For instance, if the time to compete is

reduced, you must either reduce the performance requirements/objectives or increase the cost (meaning resources).

Also, if new tasks are added to the project, increasing the scope, then one or more of the other pieces — performance or cost or time — must be increased to accommodate the change.


Project Methodology

Documentation about the consistent way of running projects is called a methodology. It prescribes what kinds of steps must be taken, what kinds of documents must be produced at each step, what kinds of approvals are needed for certain aspects of the project, how changes will be handled, and what records must be filed when the project is closed out.

It must also specify what approvals are needed for various actions, such as procurement, changes to plan, budget variances, and risks.

Project Methodology (cont.)

It should tell who is responsible for various aspects of the project, and it should spell out the roles and responsibility of each member of the team and their accountability and also the limits of each stakeholder's authority, .

The project methodology spells out how a kick-off meeting is to be held, who should attend, what they are required to have ready for the meeting, and when it is to take place. The same is true for status, data model, business process model, and design review meetings.

The methodology documents the project requirements and also the entrance and exit criteria for each of the phases of project development life cycle.

Project Life Cycle

Projects have a life cycle. A complete development process that takes each project from beginning to end. Life cycles are divided into phases to help structure and manage the project.

Different businesses may use different life cycles, with differing numbers of phases and differing phase names, but they are all similar and all contain the same essential activities. This training will use the following life cycle:

Project Life Cycle (cont)

Documentof

Understanding

2. Capture the Client's Requirements: their Business Processes & associated Business Rules

then Successively Decompose Each Process the 'Data Level' is reached!

1. Create the Document of Understanding ....

Overview Problem Statement High- Level Scope DRAFT Project Estimate Expected Deliverables Client Sign- off!

...

Alternative Tools to Use:

UML Use Case Diagrams

IDEF0 Business Process Modeling:AS- IS and TO-BE

Other?

3. Create the Data ModelUse ERWin!

Associate Tables with products from the previous phase

TO-BEERD

4. Create the Detailed Design Specification ...

a. Define All Business Rules in detail

b. Create the New Screen Designs & Record All Required Programming Logic Also Define & Design ...

c. All Batch Processing d. All System Interfaces e. All Reports

All SupportingDesign Docs!

UserInterfaceScreen

Designs&

5. CODE & TEST!

Using Everything producedfrom ALL previous phases!

Programming

Project Initiation

The Requirements / Analysis Phase

The Design Phase

The Construction Phase

TESTPlans!

Overlap... Overlap...

... Requirements andAnalysis typicallyextends into theData Modeling

Activity as DataModeling always

requires continuedclarification of therequirements andfurther (deeper)

analysis.

... Inevitably,the beginningof construction

uncoversdesign flawsthat must bereaddressed.

The Maintenance Phase

Confirm ALL Deployment Plans

TRAIN (immediatelyprior to Deployment)

Coordinate &Communicate ALL Plans

Deploy on Schedule!

6. Deploy the new Application after Successful Completion of the System Test ...

Deployment

7. Conduct Post- Implementation Reviews: AddressWhat went wrong?What went RIGHT?

HOW can we IMPROVE our Processes?

Focu

sed Clien

t O

bse

rvat

ions

to a

dd c

lari

fica

tion !

Post- Implementation Review(s)

8. Enhance & Fix ...

According toChange Management Guidelines For the Remaining

Life of the Application

... Collectively (OIP and Clients)determine that a

Reengineering Effort is Warranted!

Possible Reasons Why ...The Business Rules have evolved significantly,

which has caused new side- systems to 'spring up'.

The application's current Technology is no longer adequate toserve the client community's needs.

The original application was poorly designed 'the first time'resulting in a high- activity maintenance phase.

Formal, Scheduled Beginning(i.e., Kick-Off Meeting with Clients!)

A well-defined process for formally exitingEach Phase of the Project Life CycleMUST be documented and communicatedto the entire Project Team and All Clientsas part of the Document of Understanding.

All Products for Each Phase Must Pass the pre-Established Exit Criteria per the Formal Test Plan

Planning and Establishing the Project Baseline

Before you can develop a project's baseline you must complete the following tasks involved in the Definition and Planning phases: Identify the major stakeholders Establish feasibility based on priority and goals Define the project’s performance, time, cost, scope

constraints, and clear understandable requirements.

Develop a Risk Analysis Identify an overall strategy for accomplishing the

project results.

Planning and Establishing the Project Baseline (cont)

The first priority during implementation planning is to identify all of the tasks that have to be completed to meet the goals of the project and put it into a form that is easy to view and quickly understand.

The work breakdown structure (WBS) is a method of subdividing work into smaller and smaller increments to permit accurate estimates of durations, resource requirements, and costs.


The WBS plays a big role during implementation planning because it is the foundation upon which other project elements are based.

As a detailed portrait of all the work involved in a project, a WBS also illustrates the scope (or magnitude) of a project.

This is important because stakeholders are sometimes surprised at the cost estimates, and the WBS helps to see why the project is going to cost as much as you have estimated.


Because the WBS lists all project tasks, it also provides the basis upon which resource assignments and task durations can be made. The task duration estimates are used to calculate labor costs for all work so that a labor budget and schedule for the project is developed.


A finished WBS looks similar to an organizational chart.

It is a graphical listing of the hierarchy of work to be accomplished.

A finished WBS, sequences the tasks using a technique called a network diagram, break identified tasks down into greater levels of detail .


The final step in developing the WBS is to distribute the final draft to key stakeholders for review.

Using a ski trip as an example, you ask you develop and review the following WBS.


Further a network diagram is developed It represents project tasks in a logical order,

going left to right and allow you to put the tasks (from the WBS) into a graphical representation that shows the work flow and the relationships between project tasks.

It is the roadmap for the project and identifies the critical path for the project. The critical path is the longest path it takes to

complete the project, from start to finish.


The illustration pinpoints what tasks must precede others, those dependent on other tasks, which are parallel and also those tasks which can be completed at the same time.

Roles and Responsibilities

Project Sponsor Project Manager Project Programming Team Focus Group of Customers/Users Stakeholders

Process Review The purpose of a process review is to learn from

experience so that we can avoid those things that were not done well and continue doing those things that were done well.

It is not a witch-hunt. If we go about it in a "blame and punishment" way, people will hide their faults. If we go on a witch-hunt, we risk creating witches where none existed before.

Where do Projects Fail?

Documents

ELT Project Management Presentation by Bob Morlock