Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Principles of Enterprise Project Management

51 views

Published on

the integration of planning, scheduling, cost, and reporting requires a  clear and executable system, architecture. This project provides the first step in integrating Microsoft Project Professional with Cost View and wInsight to form an Enterprise Project Management platform.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Principles of Enterprise Project Management

  1. 1. Glen B. Alleman 5.18.05 Enterprise Project Management Case Study The integration of planning, scheduling, cost, and reporting requires a clear and executable system architecture. This project provides the first step in integrating Microsoft Project Professional with Cost View and winSight to form an Enterprise Project Management platform
  2. 2. Glen B. Alleman 5.19.05 Scope of Enterprise Project Management  Aligning resource management, schedule and cost through collaborative applications:  Cost management system  Time and Labor  Microsoft Project Professional™  Deliver integrated capabilities to:  CAMs, Planner, IPTs through Project Web Access (PWA), Project Professional (desktop) and Cost View.
  3. 3. Glen B. Alleman 5.19.05 Themes of Enterprise Project Management Application Integration Theme  Outcome Seamless integration between applications  Ease of use, training, auditing Data integrity avoids “manual” verification  Trust of data and work processes “Pull” (rather than push) paradigms provide integrity, timeliness, and robust architectures.  Stateless (asynchronous) systems easier to use and maintain Concurrency of data in the hands of the users Flexible of data configuration  Focused on project level use for planning and resource management Focused on SSC use for cost management
  4. 4. Glen B. Alleman 5.19.05 The Challenge of Integrating Heterogeneous Systems  “Federation” is a better term than “Integration”  Systems are loosely coupled and operate asynchronously  Data exchanged between system with integrity  Type definition (units of measure)  Range verification  Calendar mapping  Reconciliation done through tools rather than by hand  Data exchanged through “bridge” applications  Semantics of the data travels with the exchange  Federation goals  All data is trusted and traceable to its source – Data Integrity  Duplicate transactions produce in a single result – Indepotence  Transactions can be reversed, replaced, or undone – Reversibility  Inconsistent data cannot be entered into the system – Referential integrity
  5. 5. Glen B. Alleman 5.19.05 High Level Integration Architecture  Data Interfaces use existing formats, mapped during output process.  Data created at the point of origin, no down stream processing.  Data “pulled” from one system to another at users request
  6. 6. Glen B. Alleman 5.19.05 Data, Format, Semantics, Integrity  Units of measure across the three systems (Project Server, winSight, Cost View)  Dollars?  Time?  Resources?  Truncation options  Characters – how much detail must be carried in each database record?  Values – can monetary and duration records be “scaled?”  Breakdown structure maintenance  WBS fidelity – how far down the WBS tree can routine changes be made to meet project needs?  Resource structures – how will named resources be allocated  CAM structures – how far down the WBS tree will the CAMs be able to make routine changes (subcontractors)
  7. 7. Glen B. Alleman 5.19.05 IMP for the Bridging Project  Define Baseline Configuration  Server configuration defined  Desktop configuration defined  Project profile understood with impacts  User profile understood with impacts  Define minimum external interfaces  Data exchange formats defined  Exchange workflow defined  Validation of data and workflow complete  Deployment minimum baseline system for defined users  resources defined  Cost View interface functionally complete
  8. 8. Glen B. Alleman 5.19.05 What Does “Done” Mean for HST HRDVM?  Planner creates a resource loaded schedule in chosen scheduling tool  Integrates schedule to and from contributors to form a true Integrated Master Schedule  Costs assigned to resources roll up to integrated cost database (Cost View)  Actuals arrive from ERP system  Project performance displayed in EV terms
  9. 9. Glen B. Alleman 5.19.05 Deliverables  Baseline platform for compliance with the most RFPs  Manloaded schedule  IPT members integrated  Integration of Project Server with Cost View for corporate level reporting of project performance  Rolled up costs for labor and ODC’s  Integration of subcontractors and IPT members to enable a distributed execution of the program  Project Web Access  Systems architecture for full rollout  IDEFØ architecture for major components and their interactions
  10. 10. Glen B. Alleman 5.19.05 Enterprise Project Deliverables  System requirements analysis  Reconfirmation of previous planning tools requirements  Profile of user community  System architecture  Data elements  Process elements  Business process description  Deployment Plan  Hardware and software components  Operational requirements  Parametric cost models  Risk mitigation plan
  11. 11. Glen B. Alleman 5.19.05 Enterprise Top Level System Requirements
  12. 12. Glen B. Alleman 5.18.05 Cost and Schedule Integration Integrating Microsoft Project and Artemis Cost View is a critical success factor for Enterprise Project Management
  13. 13. Glen B. Alleman 5.19.05 Cost and Schedule Integration  Issue: Microsoft Project can not export BCWS and BCWP directly to CostView™:  Microsoft Project calculates time-scaled BCWS using only the standard Gregorian calendar. Lockheed Martin uses unique accounting calendars. If BCWS, calculated using a standard calendar, were uploaded to CostView, using a LMC unique calendar, the data would be erroneous  MS Project can calculate earned value (BCWP) at the task level but can not rollup task level BCWP into specified work-package  To upload MS Project files to CostView they must be in a specific format
  14. 14. Glen B. Alleman 5.19.05 Cost and Schedule Integration  Solution: Compliance Software Technology Export forProject™ can fully integrate MS Project and Artemis CostView  Compliance Software Technology, Inc. (CSTI) provides Earned Value Management Systems compliant with OMB A-11, Section 7 and the American National Standards Institute/Electronic Industries Alliance (ANSI/EIA) Standard 748.  CSTI is a Gold Certified Microsoft Partner, serving customers including ITT Industries, Northrop Grumman, ManTech Solutions and Technologies Corporation, Applied Signal Technology, Inc., and Computer Science Corporation, supporting the U.S. Department of Defense (DoD), U.S. Department of Energy (DoE), NASA, IRS, and other government entities. CSTI also serves companies in Petrochemical, Construction, Manufacturing, and Airline Industries.
  15. 15. Glen B. Alleman 5.19.05 Cost and Schedule Integration  Users can define custom accounting calendars with CSTI’s Export forProject  User pick dates of accounting periods
  16. 16. Glen B. Alleman 5.19.05 Cost and Schedule Integration  Tasks rolled up into Work Packages and Control Accounts  Project Percent Work Complete calculates Earned Value Progress using identical methods to AMS RTP
  17. 17. Glen B. Alleman 5.19.05 Cost and Schedule Integration  CostView read only file formatted from Microsoft Project  Directly imported to CostView
  18. 18. Glen B. Alleman 5.19.05 Cost and Schedule Integration  Tests summarize and calculate BCWS and BCWP in Microsoft Project and transfer it to a live CostView database.  Calculations compared to RTP’s output to ensure the integrity of Microsoft Project’s calculations.  BCWS and BCWP from the 1,500 line schedule were successfully imported into a CostView database  BCWS and BCWP files generated for the 5,500 and 15,500 line schedules but were not loaded into CostView, because of the lack of CostView test server space
  19. 19. Glen B. Alleman 5.19.05 Cost and Schedule Integration  Test processing time results Processing Time 0.00 5.00 10.00 15.00 20.00 25.00 30.00 35.00 40.00 45.00 1,500 Tasks 5,500 Tasks 15,500 Tasks # of Resource Loaded Tasks Time(minutes) BCWS BCWP
  20. 20. Glen B. Alleman 5.19.05 Cost and Schedule Integration  Next steps for program  Build CostView database Construct Control Accounts and Work-packages  Construct Cost Allocation Module and rate tables  Map Charge numbers to Control accounts  Complete Schedule and resource load with hours  Detail plan schedule for first rolling wave  Resource load tasks, using hours, for first rolling wave  Load BCWS into CostView
  21. 21. Glen B. Alleman 5.18.05 Risk and Risk Mitigation In any IT project the discovery and mitigation of risk is as important as the functional operation of the system
  22. 22. Glen B. Alleman 5.19.05 Risk and Mitigation Risk  Mitigation Requirements elicitation not focused on business operations  Define business operations in IDEFØ before moving to technical requirements Consistent application requires training, support and monitoring  “Step – action” processes, Rummler Brache swim lanes, and other flow-based documentation and training Functional partitioning of hardware, databases, systems, operations, and processes not well defined  Zachman-like architecture Business process model Enterprise model System model Technical model As built Functioning enterprise Project management not focused on the user  “Joint” participants in Enterprise Project Management project
  23. 23. Glen B. Alleman 5.19.05 Mind Map Approach  Capture issues, relationships, opportunities  Collect solutions  Map solutions to Zachman or similar enterprise plan  Gain consensus from all participants  Users  Process Management stakeholders  IT stakeholders  Develop IMP/IMS for Enterprise Project Management
  24. 24. Glen B. Alleman 5.19.05 Mind Map of Current Issues
  25. 25. Glen B. Alleman 5.18.05 Thinking About Enterprise Project Management Deploying Enterprise Project Management is fraught with difficulties, very few if which are technical.
  26. 26. Glen B. Alleman 5.19.05 Thinking About Enterprise Project Management  Enterprise IT Systems are driven by standardization  Server side functions and database schemas benefits from standardization  End user functionality is driven by customer needs, contract requirements and many times familiarity  Standardization limits choice  This is a “trade space”  Operational cost / savings  Support cost / savings  Customer compliance cost / savings
  27. 27. Glen B. Alleman 5.19.05 Thinking About Enterprise Project Management  “Generally Accepted Accounting Practices” (GAAP) defines the standards for general ledger, balance sheet and accounting software  Customer needs, specific program processes define the standards for Enterprise Project Management  At the point of contact between Enterprise and Customer need  Customer facing needs have little interest in the enterprise process if they conflict with customer need  Enterprise needs have little concern about localizations driven by customers  Blending the requirements for enterprise consistency and customer localization is the challenge of Enterprise Project Management
  28. 28. Glen B. Alleman 5.19.05 Thinking About Enterprise Project Management  Separation of Concerns is the path to success for Enterprise Project Management  Keys to success  Define shared data and work processes  Define localized data and work processes  Isolate data and process to eliminate undesirable impacts of enterprise processes  Push all “extra effort” onto the localized processes

×