Your SlideShare is downloading. ×
lesson 3
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

lesson 3

501

Published on

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
501
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
17
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Teaching Tips Key point to emphasize is that every IT project is unique, a factor that has made project management extremely challenging across the industry. Organizations today are placing considerably more importance on project management skills because of the impact information technology has on the business. Because of the tremendous amount of monies spent on reengineering systems because of Y2K or ERP, organizations can’t afford the project failures which were very much commonplace in the past. Project management is a cross life cycle activity  It can be useful to characterize process management as providing the “templates” (much as a word processor) for project management. But just as word processing templates must be managed and improved from time to time, so must process templates be improved and managed. 
  • Teaching Notes Most organizations pursuing the CMM are targeting Level 3, that is, consistently using a standardized process or methodology to develop all systems. CMM Level 2 deals with project management. CMM Level 3 deals with what has come to be known as process management.
  • Teaching Notes The major cause of project failure— most project managers were not educated or trained to be project managers ! Just as good programmers don't always go on to become good systems analysts, good systems analysts don't automatically perform well as project managers. To be a good project manager, you should be educated and skilled in the “art of project management.”
  • Teaching Notes There exists a core set of competencies that good project managers possess. Some of these competencies can be taught, both in courses, books, and professional workshops; however, you should immediately recognize that some of these competencies come only with professional experience in the field. First, you usually cannot manage a process you have never used. Second, you cannot manage a project without understanding the business and culture that provides a context for the project.
  • Teaching Notes The project management functions were derived from classic management functions. Project management functions are dependent upon interpersonal communications between the project manager, the team, and other managers.
  • Teaching Tips Emphasize that these measurements are from the perspective of the project manager. Failures and limited successes far outnumber successful information systems. Some studies show that 60-75% of all IT projects can be considered failures.
  • Teaching Notes PERT, which stands for Project Evaluation and Review Technique , was developed in the late 1950s to plan and control large weapons development projects for the U.S. Navy. The Gantt chart, first conceived by Henry L. Gantt in 1917, is the most commonly used project scheduling and progress evaluation tool. The tools are not mutually exclusive (especially when PERT is based on “activity on the node” conventions). That is why (and how) most project management software tools maintain both views simultaneously.
  • Teaching Tips PERT was developed to make clear the interdependence between project tasks before those tasks are scheduled. The boxes represent project tasks (we used phases from Chapter 3). (The content of the boxes can be adjusted to show various project attributes such as schedule and actual start and finish times.) The arrows indicate that one task is dependent upon the start or completion of another task. The “data” recorded in the nodes on a PERT chart vary with project management software tools. Microsoft Project supports different combinations of data in the nodes. See the comments at the beginning of the IG for an explanation of the “activity on the node: convention.
  • Teaching Tips Gantt charts offer the advantage of clearly showing overlapping tasks, that is, tasks that can be performed at the same time. The bars can be shaded to clearly indicate percentage completion and project progress. The figure demonstrates which phases are ahead and behind schedule at a glance. The popularity of Gantt charts stems from their simplicity—they are easy to learn, read, prepare, and use.
  • Teaching Tips The previous slide’s Gantt chart was built using Microsoft Visio . This one was built with Microsoft Project . Emphasize that Gantt charts can also show milestones and intertask dependencies.
  • Teaching Tips Notice that summary tasks do not have dependencies and are represented in black. The authors chose to use red to depict critical tasks (discussed later in the chapter. Milestones are depicted in teal.
  • This slide becomes the organizing model for the rest of the chapter.
  • No additional notes
  • Teaching Notes In consulting engagements, the statement of work has become a commonly used contract between the consultant and client. But the approach works equally well for internal system development projects to establish a contract between business management and the project manager and team.
  • No additional notes
  • No additional notes
  • Teaching Notes A WBS may or may not specify milestones. Teaching Tips Tasks must be broken down to a level at which they are manageable. Some experts suggest that a task must be accomplished within 40 working hours or further subdivided into tasks until they can.
  • Teaching Notes An important thing to note is that WBS’s represent a form of outlining and decomposition. As a rule of thumb, a task is broken down to two or more subtasks, but no task should have more than six subtasks.
  • Teaching Notes Recognize that the chapter demonstrated only one approach to estimating. The terminology used is consistent with Microsoft Project’s. Project actually allows the project manager to modify this formula to reflect his or her personal experience.
  • The default in most project management software packages is “finish-to-start.” The other options are provided to improve scheduling flexibility based on intertask dependency.
  • No additional notes
  • Teaching Notes In the event that the project manager is given a deadline to meet, reverse scheduling strategy is ideal.
  • No additional notes
  • Teaching Notes Before resources can be assigned to a project/task, the analyst must obtain the various stakeholders’ commitment of those resources.
  • No additional notes
  • No additional notes
  • Teaching Notes It should be noted that resource leveling will be an ongoing activity since the schedule and resource assignments are likely to change over the course of a project.
  • No additional notes
  • No additional notes
  • No additional notes
  • No additional notes
  • Teaching Notes The explanation of identifying the critical path is a simplified description. Identifying the critical path for large complex projects with many paths can be quite challenging. There are other approaches that can be used to identify the critical path (see Wysocki et al.).
  • No additional notes
  • Teaching Notes Emphasize that this is merely a sample. Encourage students to consider that many organizations have their own reporting standards to report project progress. In addition, many methodologies provide templates for various reporting needs.
  • Teaching Notes Emphasize that this is merely a sample. Encourage students to consider that many organizations have their own reporting standards to report project progress. In addition, many methodologies provide templates for various reporting needs.
  • Transcript

    • 1. Requirements Engineering Lesson 3 PROJECT MANAGEMENT
    • 2. Project and Project Management
      • A project is a [temporary] sequence of unique, complex, and connected activities having one goal or purpose and that must be completed by specific time, within budget, and according to specification.
      • Project management is the process of scoping, planning, staffing, organizing, directing, and controlling the development of an acceptable system at a minimum cost within a specified time frame.
    • 3. Project versus Process Management
      • Project management is the process of scoping, planning, staffing, organizing, directing, and controlling the development of an acceptable system at a minimum cost within a specified time frame.
      • Process management is an ongoing activity that documents, manages the use of, and improves an organization’s chosen methodology (the “process”) for system development. Process management is concerned with the activities, deliverables, and quality standards to be applied to all projects.
    • 4. Causes of Project Failure
      • Failure to establish upper-management commitment to the project
      • Lack of organization’s commitment to the system development methodology
      • Taking shortcuts through or around the system development methodology
      • Poor expectations management
      • Premature commitment to a fixed budget and schedule
      • Poor estimating techniques
      • Overoptimism
      • The mythical man-month (Brooks, 1975)
      • Inadequate people management skills
      • Failure to adapt to business change
      • Insufficient resources
      • Failure to “manage to the plan”
    • 5. Project Manager Competencies
      • Business awareness
      • Business partner orientation
      • Commitment to quality
      • Initiative
      • Information gathering
      • Analytical thinking
      • Conceptual thinking
      • Interpersonal awareness
      • Organizational awareness
      • Anticipation of impact
      • Resourceful use of influence
      • Motivating others
      • Communication skills
      • Developing others
      • Monitoring and controlling
      • Self-confidence
      • Stress management
      • Concern for credibility
      • Flexibility
      (Adapted from Wysocki, Beck, and Crane, Effective Project Management: How to Plan, Manage, and Deliver Projects on Time and within Budget.)
    • 6. Project Management Functions
        • Scoping
        • Planning
        • Estimating
        • Scheduling
        • Organizing
        • Directing      
        • Controlling
        • Closing
    • 7. Measures of Project Success
        • The resulting information system is acceptable to the customer.
        • The system was delivered “on time.”
        • The system was delivered “within budget.”
        • The system development process had a minimal impact on ongoing business operations.
    • 8. The Variables of Project Management
      • Can somewhat vary the following factors.
      • 1. The total cost of the project,
        • e.g., increase expenditures
      • 2. The capabilities of the product,
        • e.g., subtract from a list of features
      • 3. The quality of the product,
        • e.g., increase the mean time between failure
      • 4. The date on which the job is completed.
        • e.g., reduce the schedule by 20%
        • e.g., postpone project's completion date one month
    • 9. Bullseye Figure for Project Variables cost capability duration defect density Target : $70K Target : 30 wks Target : 4 defects/Kloc Target : 100% Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 10. Bullseye Figure for Project Variables cost capability duration defect density Target : $70K Actual : 100% Target : 30 wks Target : 4 defects/Kloc this project Actual : 1 defect/Kloc Actual : 20 wks Actual : $90K Target : 100% Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 11. A Road Map for Project Management Planning 1. Understand project content, scope, & time frame 2. Identify development process ( methods, tools, languages, documentation and support ) 3. Determine organizational structure (organizational elements involved) 4. Identify managerial process (responsibilities of the participants) 6. Develop staffing plan 5. Develop schedule ( times at which the work portions are to be performed ) 7. Begin risk management 8. Identify documents to be produced 9. Begin process itself
    • 12. Hierarchical Project Management Organizations Larger Projects: Smaller Projects: No separate Marketing? No separate QA organization?
      • Subdivide QA into testing, …?
      • Subdivide Engineering into
        • system engineering, …?
      Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 13. Horizontal Project Management Organizations Gil Warner Team leader Ian Corliss Team member Nel Tremont Team member Fran Smith Team member Team facilitator? Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 14. Peer Organizations for Larger Projects Team of leaders Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 15. Organize a Team
      • 1. Select team leader: responsibilities:
        • ensure all project aspects active
        • fill all gaps
      • 3. Designate leader roles & document responsibilities
        • team leader: proposes and maintains… SPMP
        • configuration management leader: ... SCMP
        • quality assurance leader: ... SQAP, STP
        • requirements management leader: ... SRS
        • design leader: ... SDD
        • implementation leader: ... code base
      • 2. Leaders’ responsibilities:
        • propose a straw man artifact (e.g. SRS, design)
        • seek team enhancement & acceptance
        • ensure designated artifact maintained & observed
        • maintain corresponding metrics if applicable
      • 4. Designate a backup for each leader
      One way to ... Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 16. The Four Risk Activities
      • (1) Identification
      • Mindset: try to continually identify risks
      • (2) Retirement (Mitigation) planning
      • (3) Prioritization
      • (4) Retirement or mitigation
      Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 17. The Risk Management Mindset Project finish Project start Identification Retirement 2. “Java skills not high enough.” 1. “May not be possible to superimpose images adequately.” 1. Retirement by conquest: Demonstrate image super- imposition Risk 1 Risk 2 Risk 1 Project finish Risk 2 2. Retirement by avoidance: Use C++ Project start Graphics reproduced with permission from Corel. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 18. Identify and Mitigate Risks
      • 1.* Each team member spends 10 mins. exploring his or her greatest fears for the project’s success
      • 2.* Each member specifies these risks in concrete language, weights them, writes retirement plans, (see format above) & e-mails to the team leader
      • 3.* Team leader integrates and prioritizes results
      • 4. M Group spends 10 mins. seeking additional risks
      • 5. M Team spends 10 mins. finalizing the risk table
        • Designates responsible risk retirement engineers
      • 6.** Responsible engineers do risk retirement work
      • 7. M Team reviews risks for 10 mins. at weekly meetings
        • responsible engineers report progress
        • team discusses newly perceived risks and adds them
      *:in advance of first meeting M : at meeting **: between meetings One way to ...
    • 19. Choosing development tools and support – [CASE Tools ]-
      • To support project management
        • schedule
        • work breakdown
      • To support configuration management
      • For managing requirements
      • For drawing designs
        • functional
        • object-oriented
        • use-case-based
      • Tracing tools
        • requirements to designs
        • designs to code
      • To support testing
      • To support maintenance
    • 20. Creating schedules: high level planning
      • Methods
        • Backward Planning
        • Forward Planning
    • 21. High Level Task Chart with Fixed Delivery Date: Month 1 1 2 3 4 Month 2 1 2 3 4 Month 3 1 2 3 4 Month 4 1 2 3 4 Month 5 1 2 3 4 Milestones Delivery SRS Complete Iteration 1 Iteration 2 Freeze requirements Risk identification & retirement SCMP complete SQAP complete SPMP rel. 1 complete Prep. for maintenance Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 22. Create an Initial Schedule
      • 1. Indicate the milestones your must observe
        • usually includes delivery date
      • 2. Back these up to introduce the milestones you need
        • e.g., begin system testing well before delivery
      • 3. Designate a time at which all requirements frozen
      • The remaining steps depend on the process used.
      • We will assume an iterative process.
      • 4. Show first iteration: establishes minimal capability
        • usually: keep it very modest, even trivial, in capability
        • benefit: exercises the development process itself
      • 5. Show task of identifying & retiring risks
        • starting from project inception
      • 6. Show unassigned time (e.g., week) near middle?
      • 7. Complete the schedule
      Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 23. Level Labor Allocation for Fixed Labor Total Month 1 1 2 3 4 Month 2 1 2 3 4 Month 3 1 2 3 4 Month 4 1 2 3 4 Month 5 1 2 3 4 Milestones Release to production Complete testing Iteration 1 Iteration 2 Freeze requirements Risk ID & retire 2 2 2 3 2 2 3 2 2 2 1 1 1 4 4 4 3 3 4 4 4 4 4 4 3 3 4 4 4 4 3 3 4 4 4 4 4 4 4 4 4 4 4 4 4 Given team size: To be assigned 4 Hal vacation Karen vacation Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 24. Project Management Tools & Techniques
      • A PERT chart is a graphical network model that depicts a project’s tasks and the relationships between those tasks.
      • A Gantt chart is a simple horizontal bar chart that depicts project tasks against a calendar. Each bar represents a named project task. The tasks are listed vertically in the left-hand column. The horizontal axis is a calendar timeline.
    • 25. PERT Chart 5-3-2001 5-12-2001 5-3-2001 5-11-2001 Preliminary Investigation 5-12-2001 6-12-2001 5-12-2001 6-14-2001 Problem Analysis 5-28-2001 7-15-2001 5-30-2001 7-18-2001 Requirements Analysis 6-13-2001 7-30-2001 6-13-2001 8-3-2001 Decision Analysis 9-10-2001 12-14-2001 TBD TBD Implementation 7-19-2001 11-13-2001 7-20-2001 In Progress Construction 7-3-2001 9-25-2001 7-5-2001 10-9-2001 Design 5-3-2001 N/A 5-3-2001 N/A Project Initiation Scheduled Start Scheduled Finish Actual Start Actual Finish Task Scheduled Start Scheduled Finish Actual Start Actual Finish Task intertask dependency Legend
    • 26. Gantt Chart Incomplete Task Complete Task Legend ID 1 2 3 4 5 6 7 Preliminary investigation Problem analysis Requirements analysis Decision analysis Design Construction Implementation May Jun Jul Aug Sep Oct Nov Dec 2001 Task Name Today
    • 27. Microsoft Project Gantt Chart
    • 28. Microsoft Project PERT Chart
    • 29. Project Management Life Cycle
    • 30. Joint Project Planning Strategy
      • Joint project planning (JPP) is a strategy wherein all stakeholders in a project (meaning system owners, users, analysts, designers, and builders) participate in a one-to-three day project management workshop, the result of which is consensus agreement on project scope, schedule, resources, and budget. (Of course, subsequent workshops or meetings may be required to adjust scope, budget, and schedule.)
    • 31. Negotiate Scope
      • Scope defines the boundaries of a project—What part of the business is to be studied, analyzed, designed, constructed, implemented, and ultimately improved?
        • Product
        • Quality
        • Time
        • Cost
        • Resources
      • A statement of work is a narrative description of the work to be performed as part of a project. Common synonyms include scope statement , project definition , project overview , and document of understanding .
    • 32. Statement of Work
      • I. Purpose
      • II. Background
      • A. Problem, opportunity, or directive statement
      • B. History leading to project request
      • C. Project goal and objectives
      • D. Product description
      • III. Scope
      • (notice the use of your information system building blocks)
      • A. Stakeholders
      • B. Data
      • C. Processes
      • D. Locations
      • IV. Project Approach
      • A. Route
      • B. Deliverables
      • V. Managerial Approach
      • A. Team building considerations
      • B. Manager and experience
      • C. Training requirements
      • D. Meeting schedules
      • E. Reporting methods and frequency
      • F. Conflict management
      • G. Scope management (continued)
    • 33. Statement of Work (concluded)
      • VI. Constraints
      • A. Start date
      • B. Deadlines
      • C. Budget
      • D. Technology
      • VII. Ballpark Estimates
      • A. Schedule
      • B. Budget
      • VIII. Conditions of Satisfaction
      • A. Success criteria
      • B. Assumptions
      • C. Risks
      • IX. Appendices
    • 34. Identify Tasks
      • A work breakdown structure (WBS) is a hierarchical decomposition of the project into phases, activities, and tasks.
      • Milestones are events that signify the accomplishment or completion of major deliverables during a project.
    • 35. Work Breakdown Structures
      • 1 Phase 1 of the project …
      • 2 Phase 2 of the project …
      • 2.1 Activity 1 of Phase 2 …
      • 2.2 Activity 2 of Phase 2
      • 2.2.1 Task 1 of Activity 2.2 in Phase 2
      • 2.2.2 Task 2 of Activity 2.2 in Phase 2
      • 2.2.3 Task 3 of Activity 2.2 in Phase 2
      • 2.3 Activity 3 of Phase 2 …
      • 3 Phase 3 of the project …
      = PROJECT GOAL 0 PHASE 2 PHASE 3 PHASE 1 ACTIVITY 2.2 ACTIVITY 2.1 ACTIVITY 2.3 TASK 2.2.2 TASK 2.2.1 TASK 2.2.3
    • 36. Estimate Task Durations
      • 1.  Estimate the minimum amount of time it would take to perform the task. We'll call this the optimistic duration (OD).
      • 2.  Estimate the maximum amount of time it would take to perform the task. We'll call this the pessimistic duration (PD).
      • 3.  Estimate the expected duration (ED) that will be needed to perform the task.
      • 4.  Calculate the most likely duration (D) as follows:
      • D = (1 x OD) + (4 x ED) + (1 x PD) 6
    • 37. Specify Intertask Dependencies
      • Finish-to-start (FS)—The finish of one task triggers the start of another task.
      • Start-to-start (SS)—The start of one task triggers the start of another task.
      • Finish-to-finish (FF)—Two tasks must finish at the same time.
      • Start-to-finish (SF)—The start of one task signifies the finish of another task.
    • 38. Entering Intertask Dependencies
    • 39. Scheduling Strategies
      • Forward scheduling establishes a project start date and then schedules forward from that date. Based on the planned duration of required tasks, their interdependencies, and the allocation of resources to complete those tasks, a projected project completion date is calculated.
      • Reverse scheduling establishes a project deadline and then schedules backward from that date. Essentially, tasks, their duration, interdependencies, and resources must be considered to ensure that the project can be completed by the deadline.
    • 40. A Project Calendar
    • 41. Assign Resources
      • People—inclusive of all the system owners, users, analysts, designers, builders, external agents, and clerical help that will be involved in the project in any way, shape, or form.
      • Services—a service such as a quality review that may be charged on a per use basis.
      • Facilities and equipment—including all rooms and technology that will be needed to complete the project.
      • Supplies and materials—everything from pencils, paper, notebooks, toner cartridges, etc.
      • Money—A translation of all of the above into the language of accounting—budgeted dollars!
    • 42. Defining Project Resources
    • 43. Assigning Project Resources
    • 44. Resource Leveling
      • Resource leveling is a strategy used to correct resource overallocations by some combination of delaying or splitting tasks .
      • There are two techniques for resource leveling:
      • task delaying
      • task splitting
    • 45. Task Splitting and Delaying
      • The critical path for a project is that sequence of dependent tasks that have the largest sum of most likely durations. The critical path determines the earliest possible completion date of the project.
        • Tasks that are on the critical path cannot be delayed without delaying the entire project schedule. To achieve resource leveling, critical tasks can only be split.
      • The slack time available for any noncritical task is the amount of delay that can be tolerated between the starting time and completion time of a task without causing a delay in the completion date of the entire project.
        • Tasks that have slack time can be delayed to achieve resource leveling
    • 46. Direct the Team Effort
      • Supervision resources
        • The DEADLINE – A Novel About Project Management
        • The One Minute Manager
        • The Care and Feeding of Monkeys
      • Stages of Team Maturity (see figure to the right)
      Ÿ Establish structure and rules Ÿ Clarify team member relationships Ÿ Identify responsibilities Ÿ Develop a plan to achieve goals ORIENTATION STAGE Ÿ Resolve interpersonal conflict Ÿ Further clarify rules and goals Ÿ Develop a participative climate INTERNAL PROBLEM-SOLVING STAGE Ÿ Direct team activity toward goals Ÿ Provide and get feedback Ÿ Share ideas–growing cohesion Ÿ Individuals feel good about each other GROWTH AND PRODUCTIVITY STAGE Ÿ More feedback and evaluation Ÿ Adherence to team norms Ÿ Roles of team strengthened Ÿ Strong team motivation to share goals EVALUATION AND CONTROL STAGE FORMING STORMING NORMING PERFORMING
    • 47. Monitor and Control Progress
      • Progress reporting
      • Change management
      • Expectations management
      • Schedule adjustments —critical path analysis (CPA)
    • 48. Progress on a Gantt Chart
    • 49. Critical Path Analysis (and Slack Time)
      • Using intertask dependencies, determine every possible path through the project.
      • For each path, sum the durations of all tasks in the path.
      • The path with the longest total duration is the critical path .
        • The critical path for a project is that sequence of dependent tasks that have the largest sum of most likely durations . The critical path determines the earliest completion date of the project.
        • The slack time available for any noncritical task is the amount of delay that can be tolerated between the starting time and completion time of a task without causing a delay in the completion date of the entire project.
    • 50. Critical Path The critical path is highlighted in red TASK C Fri 2/9/01 2 days Fri 2/9/01 0 days TASK D Tue 2/20/01 7 days Tue 2/20/01 0 days TASK I Tue 2/27/01 5 days Tue 2/27/01 0 days TASK E Mon 2/19/01 6 days Tue 2/20/01 1 day TASK B Wed 2/7/01 2 days Wed 2/7/01 0 days TASK A Mon 2/5/01 3 days Mon 2/5/01 0 days TASK H Thu 2/15/01 1 day Tue 2/20/01 3 days TASK F Wed 2/14/01 3 days Fri 2/16/01 2 days TASK G Fri 2/16/01 2 days Tue 2/20/01 2 days Duration Slack Time
    • 51. Sample Outline for a Progress Report
      • I. Cover Page
      • A. Project name or identification
      • B. Project manager
      • C. Date or report
      • II. Summary of progress
      • A. Schedule analysis
      • B. Budget analysis
      • C. Scope analysis (describe any changes that may have an impact on future progress)
      • D. Process analysis (describe any problems encountered with strategy or methodology)
      • E. Gantt progress chart(s)
      • III. Activity analysis
      • A. Tasks completed since last report
      • B. Current tasks and deliverables
      • C. Short term future tasks and deliverables
      • IV. Previous problems and issues
      • A. Action item and status
      • B. New or revised action items
      • 1. Recommendation
      • 2. Assignment of responsibility
      • 3. Deadline
      • (continued)
    • 52. Sample Outline for a Progress Report (concluded)
      • V. New problems and issues
      • A. Problems
      • (actual or anticipated)
      • B. Issues
      • (actual or anticipated)
      • C. Possible solutions
      • 1. Recommendation
      • 2. Assignment of responsibility
      • 3. Deadline
      • VI. Attachments
      • (include relevant printouts from project management software)
    • 53. PowerPoint Alternative Sample initial status report
    • 54. May 30, 2000 Integrated Strategic Systems Plan Two Week Status Report
    • 55. The purpose of today's meeting:
      • Report on first two weeks
      • Agree on hypothesis
      • Agree of business issues
      • Next step - detailed IT assessment
    • 56. The project objective is to:
    • 57. The project scope is focused on the processes and technologies that drive manufacturing capacities, costs and efficiencies .
    • 58. The study deliverables will be linked to the NMMC business strategies and processes. Future I/T Environment and Plan Technology Governance Processes Skills Current I/T Environment MotorCo Corporate and Business Unit Strategies and Processes Technology Governance Processes Skills Requirements for Linkage Best Practices Technologies & Solutions Competitor's Technology Gap Closing Measures Potential Technology Usage Deliverables: 2-3 year strategic plan to align with Smyrna production goals I/T infrastructure assessment I/T Strategic Systems Plan - Time-phased Plan - Cost/Benefit Analysis
    • 59. The work-plan is aggressive covering fourteen weeks we are on schedule for 18 August 2000 We are here
    • 60. sTs has committed the following resources to this project
      • Full Time :
      • Engagement Manager & IT Strategist - Tony Sullivan
      • Process Analyst - Kumar Bhatt
      • IT Architect - Stephen Perun
      • Part Time:
      • IT Strategy: Carl Straub
      • IT Assessment: MotorCo IT Support
    • 61. We are working under the following hypothesis
      • MotorCo intends to significantly increase it's North American production. The current information technology base will not allow increase in product mix, multiple plants or three shift operations
      • Systems are old and difficult to change
      • Batch operation precludes real time information
      • Knowledge of some systems is "retiring"
    • 62. The last two weeks was spent ......
      • We collected requirements from all the meetings and held a special meeting for your direct reports or representatives to gather their requirements (5/25):
        • completing the current process understanding
        • completing the current IT architecture map
        • developing business requirements for the expanded
        • production scope
    • 63. Last week we met with four major areas of production control to understand the current process
      • Tuesday, 5/23 2:30-5:00 Production Planning
      • Takeshi (Todd)
      • Steve
      • Wednesday, 5/24 7:30-11:30 Production Scheduling
      • Bill
      • Roy D
      • Bruce
      • Mike
      • Wednesday, 5/24 1:00-5:00 Inventory Control
      • Art
      • Pete
      • Tommy
      • Bob
      • Terry
      • Thursday, 5/25 7:30-11:30 Crossdock
      • Art
      • Pete
      • Bob
      • Beth L
      • Melody
      • Elmer H
      • Greg J
    • 64. Problem: We do not have a complete understanding of MotorCo's current Business Objectives to completely align a new IT Strategy
      • To properly align IT plans a complete understanding of Business Objectives is required........
      • Example: Increase production throughput
        • Optimizing throughput tends to group like units (Build to Plan)
        • e-business looks at order quantities of one.
    • 65. Over the next two weeks we plan to meet with the following groups
      • PMCS (6/7)
        • Bryan
        • Dan t
        • Earl
        • Randy
      • Production Purchasing (6/9)
      • Financial Systems (6/8)
        • Vince
        • Bill
        • Mary
      • Transportation
      • Decherd (6/8)
        • Brent
    • 66. Issues
      • None
    • 67. Questions?

    ×