1 / 65

Fully Supporting the Entire Project Lifecycle with Information Technology

Fully Supporting the Entire Project Lifecycle with Information Technology. Dr. James R. Burns, Professor College of Project Administration Texas Tech University Lubbock, Texas 79409-2101 Dr. Onur Ulgen, Professor Department of Industrial and Systems Engineering

teige
Download Presentation

Fully Supporting the Entire Project Lifecycle with Information Technology

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Fully Supporting the Entire Project Lifecycle with Information Technology Dr. James R. Burns, Professor College of Project Administration Texas Tech University Lubbock, Texas 79409-2101 Dr. Onur Ulgen, Professor Department of Industrial and Systems Engineering University of Michigan, Dearborn Dearborn, Michigan 48128

  2. Background • Existing products for project management do not support the entire lifecycle. As a result many projects fail because of • 1) poor definition of the ultimate product, • 2) a lack of specification of the Project case, or • 3) failure to determine a measurable value system by which benefit can be assessed Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  3. Existing PM Software • . The existing PM software product space is populated with offerings that support only two of the four stages of the project lifecycle—a) planning and budgeting and b) execution and control. Existing tools do not support the beginning stage—definition and conceptualization--nor do they support the last stage—termination and closure. Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  4. This paper proposes an architecture for a project management tool that… • subsumes existing PM tools and provides for integrated project definition, planning, development, and closure. • suggests “prototypes” of specific features one would expect a total project management support tool to provide. • uses the Internet for multi-user collaboration. Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  5. Focus • Reduction of time to project and product completion • Reduction of project and product cost • Increases in the contribution to customer-perceived value Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  6. Architecture -- Components • Reusable requirements repository • Expert system • Knowledge base • Knowledge nets, Rules, Boolean Matrices • Inference engine • Wizards • Simulation tools Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  7. Outline of Presentation Project process Basics Project Facilitation Project Knowledge Representation and Inferencing Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  8. Project Process Basics • Project processes have definable beginning and end points • Project processes have inputs consisting of information, material, energy, etc., which they transform into outputs also consisting of information, material, energy, etc. Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  9. More Project Process Basics • Project processes are created by higher-level Project processes that monitor and control their operation • Project processes report their status to their higher-level controlling Project processes Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  10. Implications for Project Process Models • They should incorporate a hierarchical structure and include process components and the relationship between the processes as a minimum • Events, resources, actors, owners can be included as the modeler requires Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  11. Process Dependency and Project Rules • Dependencies can be one-to-one, many-into-one, one-into-many, many into many • Process dependencies are determined by the Project RULES of the enterprise • Processes depend on other processes Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  12. Reuse..one key to faster, cheaper project completions • Reusable requirements • Reusable project plans and budgets • Reusable functional specifications • Reusable design docs • Reusable code • Reusable test modules • Reusable knowledge Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  13. Estimation…of time and cost • The weakest link in any project, IT or otherwise • Needed: reusable estimates of time and cost broken down by task and adjusted for the actual person doing the work • This is more than just a book of tables and formulas for determining time and cost Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  14. Knowledge reuse • About techniques for faster, cheaper completions of projects • Crashing • Fast-tracking • Increasing parallelism • Minimizing changes to requirements • Doing it right the first time • Eliminate non-value-adding work • CODIFIED EXPERTISE is needed for all of these Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  15. Knowledge related to chunking • To reduce testing time • To enhance maintainability • To reduce maintenance costs: the 1 to 3 rule • To reduce complexity • Bug fixing time goes up exponentially with increases in complexity • To create a plug and play landscape Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  16. Computer-codified knowledge assistance with… • Requirements scrubbing • Removal of safety • Management of multitasking • Management of procrastination • Increasing focus • Deciding what to measure and reward Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  17. Computer-codified knowledge assistance with… • Fire-fighting and expediting • Negotiations with stakeholders • Minimizing management interference • Change management Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  18. Codified knowledge of best practices Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  19. Change Board Daily Build and Smoke test Designing for Change Evolutionary prototyping Goal setting Inspections Joint Applications Development (JAD) Lifecycle Model Selection Measurement Miniature Milestones Outsourcing Principled Negotiation Agenda of Best Practices Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  20. Productivity Environments Rapid Development Languages Requirements Scrubbing Reuse Signing Up Spiral Lifecycle Model Staged Delivery Theory-W Management Throwaway Prototyping Timebox Development Tools Group Top-10 Risks List User-Interface Prototyping Voluntary Overtime More best Practices Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  21. Scope Management Time Management Cost Management Quality Management Integration Management Risk Management Communications Management Procurement management Human Resources Management Codified knowledge and best-practice concepts are needed for every knowledge area in project management Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  22. Measurements are a major problem with projects • Measurements should induce the parts to do what is good for the system as a whole • Measurements should direct managers to the point that needs their attention • So often it occurs that we measure the wrong thing. • The wrong measure leads to wrong behavior • Tell me how you measure me and I will show you how I behave Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  23. More Measurements -5 -5 -5 +15 Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  24. Project Knowledge Representation Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  25. Knowledge representation and Inferencing using Boolean Algebra/Binary Matrices Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  26. Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  27. Definitions • A = requirements document • B = project plan and proposal • C = functional specification • D = design document • E = code • F = test document • G = acceptance test plan • H = implementation Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  28. Notation • Let eij = 1 if there is an edge directed from i to j and 0, otherwise Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  29. Information contained in the above can be represented as Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  30. Matrix Product Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  31. Continuous Simulation • A way to capture behavioral and dynamic project knowledge • And do inferencing on it Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  32. Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  33. Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  34. Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  35. Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  36. A Project Blueprint Model Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  37. Project Rules—another way to codify project knowledge • Project rules are a shorthand language for expressing the Project knowledge • Are the declarative scripts of the project • No matter what happens, one or more project rules would control what happens after that Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  38. Project Rules • Project rules are a shorthand language for expressing the Project knowledge • Are the declarative script of the enterprise • No matter what happens, one or more Project rules would control what happens after that Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  39. The Project Rules • Any enterprise can be analyzed from a structural perspective, a functional perspective, and a behavioral or dynamical perspective (also called “viewpoint”) • Project rules apply to any and all of the enterprise perspectives Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  40. Examples of Structural Project Rules • The enterprise should have a marketing department, personnel department, finance department, accounting department, and customer service department. (Organization rule) • Annual Total Profit = Annual Total Revenue – Annual Total Expense (Entity definition) Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  41. Examples of Functional Rules • Functional rules are the rules that specify the goals and objectives of the enterprise. Basically, they collectively define the “what should be done (by whom)”. Examples of these rules are: • The enterprise should maintain at least 35% of the domestic market of product A. • The management of human resources is the responsibility of the managers throughout the company (as opposed to being established as a separate organizational unit) Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  42. Behavioral Project Rules • Used to control the preconditions and post-conditions of the state changes of the enterprise • The form is… • When certain events occur and/or certain conditions hold true, then other events are triggered and the system undergoes state change • Clearly, there is a “chain of events” that gives rise to certain observed behaviors Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  43. A Simplified Project Process Model (SBPM) • Purpose is to capture relationships between sub processes represented as nodes • Such relationships exist when there is a triggering control sequence of events between the sub process nodes • There is a temporal sequence that we shall represent with a directed link between the sub process nodes Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  44. The SBPM is a Form of Knowledge Representation • The domain knowledge K consists of two components—the set V of Project process nodes and sub process nodes • The set E of relationships among the nodes; thus • K = <V,E>; i.e., K is a dyad of V and E Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  45. A Simplified Project Process Model (Diagram) Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  46. Process Node Architecture Components • A task function that provides the services expected to be done at this node • An actor who is in charge of or responsible for the services of this node • Information storage for input/output of locally stored information • Information throughput capability Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  47. Process Node Architecture Diagram Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  48. Connectionist Approach to Project Knowledge Inferencing • The network of process nodes will have a mesh topology and might contain loops or cycles • The topology is a hierarchical one as exhibited in the following… Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  49. Design Principles for Project Knowledge System (PKS) Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

  50. Design Principles for PKS, Continued (1) Is a network representation of processing knowledge (2) Represents the relative importance of the sub-process over the whole Project process (3) Represents the influence of process nodes by weight values (4) One-node-one-process representation (non-distributed representation) Burns & Ulgen, Fully Supporting the PM Lifecycle -- USP Conference -- September 2003

More Related